That's exactly my point. Since we're discussing the merits of GWT, we should avoid points that have nothing to do with GWT per se.
To put a finer point on it: GWT does not require you to structure your app that way. If you do choose to structure your app that way, then you're making the same tradeoff that you would make if you were to go down that same path in any toolkit.
I don't see any point in discussing GWT by itself, without any comparison to other development techniques, and when you compare it to traditional approaches, the "SEO overhead" mentioned in the article is a downside.
Ok, but let's cleanly separate the concept of a tool from the concept of a technique.
The technique here is using URL fragments for history management in AJAX applications.
This tool (GWT) does not require that technique any more than JQuery does (or myriad other examples), so the comparison of the tradeoffs of using/avoiding the technique is orthogonal to the choice of tool.
Yeah, I think that section of the article could be improved.
If I were facing their problem (where they had already chosen to use URL fragments for navigation but also didn't want to miss out on crawlability) I would use a different approach than maintaining a separate set of static pages.
Instead of static pages, I would create a single servlet/cgi that would handle the URLs to these pages. The content for each URL could be created on-the-fly on the server side using some server-side browser (like HtmlUnit, Cobra or Crowbar...) to receive the requests, translate the URL into the fragment-format, run your actual javascript application (which is already written to handle such fragments) and capture the resulting DOM to send back to the actual browser that arrived via the Google search. Of course the HTML could be persisted so that this process would only need to happen once per URL. The benefit of doing it this way would be that when you deployed changes you could simply invalidate the HTML cache and let your system build them again automatically.
But it would probably be better to avoid the problem entirely by thinking about SEO needs up front.
Comments
That's exactly my point. Since we're discussing the merits of GWT, we should avoid points that have nothing to do with GWT per se.
To put a finer point on it: GWT does not require you to structure your app that way. If you do choose to structure your app that way, then you're making the same tradeoff that you would make if you were to go down that same path in any toolkit.
I don't see any point in discussing GWT by itself, without any comparison to other development techniques, and when you compare it to traditional approaches, the "SEO overhead" mentioned in the article is a downside.
Ok, but let's cleanly separate the concept of a tool from the concept of a technique.
The technique here is using URL fragments for history management in AJAX applications.
This tool (GWT) does not require that technique any more than JQuery does (or myriad other examples), so the comparison of the tradeoffs of using/avoiding the technique is orthogonal to the choice of tool.
That's good to know. From the article, it sounded like hashbang URLs were the default/preferred method of handling navigation.
Yeah, I think that section of the article could be improved.
If I were facing their problem (where they had already chosen to use URL fragments for navigation but also didn't want to miss out on crawlability) I would use a different approach than maintaining a separate set of static pages.
Instead of static pages, I would create a single servlet/cgi that would handle the URLs to these pages. The content for each URL could be created on-the-fly on the server side using some server-side browser (like HtmlUnit, Cobra or Crowbar...) to receive the requests, translate the URL into the fragment-format, run your actual javascript application (which is already written to handle such fragments) and capture the resulting DOM to send back to the actual browser that arrived via the Google search. Of course the HTML could be persisted so that this process would only need to happen once per URL. The benefit of doing it this way would be that when you deployed changes you could simply invalidate the HTML cache and let your system build them again automatically.
But it would probably be better to avoid the problem entirely by thinking about SEO needs up front.