Link Details

Great article, other problem that you forgot to mention is the memory leaks in GWT, We finally have to sit down debugging the 1+Mb of compiler generated javascript.

Somewhat vague argumentation. Yes, JavaScript is the backbone of the browser but for a certain class of relatively large and data-driven systems, you will want all the help you can get from a type-system. So while GWT might not be the best for all types of sites, it sure beats having to install some 3'rd part container (Java, Silverlight and Flash). Voted down for not even considering why we have GWT in the first place.

While the article has some valid points it misses the actual point of tools like GWT.
Unless someone comes up with a bytecode that works across all browsers Javascript is the assembly language of the web.
People who are still bashing on static typing should:
1. Learn Haskell
2. Work in a Project with more then 20 developers that have different skill levels, have experienced people leave while new ones arrive all the time
3. stop making a difference between static typing and dynamic typing Use the tool that is best for the job.
4. all the stuff I missed to list in here...

Compile time in GWT indeed can be annoying. But I for myself prefer to wait for compilation instead of having to bother with browser specific code.

I really appreciate the benefits of GWT, they outweight the downsides to me:
- cross browser compilation
- code reuse on client AND server
- nice JUnit support for client side code
- one language fits most for client AND server (besides you can easily integrate native JS in client side code)

Related link: http://www.dzone.com/links/wicket_and_gwt_compared_with_code.html

The article still has a valid point. The typical most common arguments pro-GWT are not exactly set in stone:

- cross browser compilation: the ajax library of your choice will tackle this. For the 1% cases that fall out of these, there is the jresig book.
- code reuse on client AND server: this is a valid point, but how often do you need this?
- nice JUnit support for client side code: there are plenty of junit-like libraries for javascript.
- one language fits most for client AND server: these days I am seeing articles on the two extremes of pro and against polyglot programming. For me, javascript makes me more productive than Grails.

I am not saying that GWT does not have good things, but I still think the article gives some fresh perspective to the matter.

- "cross browser compilation: the ajax library of your choice will tackle this. For the 1% cases that fall out of these, there is the jresig book" - Im no JS guru but I dont know any JS library which let you build rich-client like web applications like GWT does. GWT enables you to build web application in the same (or samiliar) way like you would build rich-client desktops apps.
- "code reuse on client AND server: this is a valid point, but how often do you need this?" - Im using this for validating user inputs. You can use the same code both for validating the input on client side and again validating the arguments of service calls on server side. This is a typical task to me, nothing exotic.
- "nice JUnit support for client side code: there are plenty of junit-like libraries for javascript." - this is true. Although GWT JUnits tests integrates nicely into the Maven2 lifecycle.

Im not saying that GWT is the one and only solution for web projects, but its my preferred technology for writing (rich client like) web applications.

"Im no JS guru but I dont know any JS library which let you build rich-client like web applications like GWT does. GWT enables you to build web application in the same (or similar) way like you would build rich-client desktops apps."

ExtJS does (it is mentioned in the article). They also include a designer tool:
http://www.extjs.com/blog/2009/10/08/ext-js-designer-preview/

About user input validation, you are right that every web framework should include a way to avoid replicating validation code. Not all frameworks come with an embedded solution out of the box.

Your point about GWT is entirely reasonable, and I agree it's a great tool for developing rich apps. It's just that I don't see the reason for so many voters against the article.

Correct me if Im wrong but ExtJS, while being a nice container for standardized UI widgets, it doesnt give you the flexibility to create custom widgets by your own. Also it doesnt allow you to customize how the wigets look like. Also it doesnt support you by implementing your own programming concepts for MVC, event handling and stuff like that.

But I agree that the article got some valid points. Though I didnt voted for the article neither up nor down.

There are plenty of themes for ExtJS out there, and sure you can extend or modify current widgets with your own. They use a class-alike component structure including inheritance mechanisms. They also include Model, View and Event classes. Having said this, I am not an ExtJS expert or anything.