When you read opinions like this, you have to interpret the author's
perspective relative to his/her incentives. Thus, GWT consultants will
observe the reasons GWT is really good. Consultants skilled in things other
than GWT will find reasons that their solutions are better. There isn't a
"right" answer.

More inline below.

On Wed, Aug 3, 2011 at 2:53 AM, Emilio Bravo <[email protected]> wrote:

> "First, in many ways, JavaScript is more powerful and expressive than
> Java, so we suspect that the generation is going in the wrong
> direction."
>

It paints a picture, but there are no facts or evidence in the above
statement. Words like "powerful" and "expressive" are popular when
discussing these sorts of topics precisely because they're vague enough that
it's hard to argue with them.

You can pick literally any topic and find people eager to take all sides.
The question is how seriously you should take the assertion made by the
author.

Do you trust the author? Why? If so, take the judgment seriously. If you
don't have any particular reason to trust the author relative to others who
have a different conclusion, then ignore the article and judge for yourself
or listen to those with more direct experience using the technology in
question.

Someone's willingness to write down their assertion doesn't make it more
correct. And no tool is right or wrong for every project.

"Secondly, it is impossible to hide a complex abstraction difference
> like that from event-driven desktop to stateless-web without leaky
> abstraction headaches eventually popping up"
>

Of course abstractions leak. We knew that when we designed GWT and the
design accounts for that. GWT generally doesn't depend on isolating you from
JS or the DOM except in cases where memory leaks are the inevitable
by-product of not adding widget-like machinery. To put that another way: the
absence of GWT's "abstractions that leak" is UI code that very likely has
memory leaks. That there are many GWT libraries that interop with
handwritten JS is among the evidence that the above statement
seems under-informed and dismissively definitive (e.g. "impossible").

"Third, it suffers from the same shortcomings of many elaborate
> frameworks, where building simple, aligned applications is quick and
> easy, building more sophisticated but not supported functionality is
> possible but difficult, and building the level of sophistication
> required by any non-trivial application becomes either impossible or
> so difficult it isn’t reasonable."
>

This one is almost funny. GWT usually gets beat up for the precise opposite:
it's good for big apps but not easy enough for small ones. Among the tens of
thousands of apps that overcame the above-asserted "abstraction headaches"
and managed to do something "sophisticated" include Angry Birds, AdWords
(with hundreds of thousands of lines of browser code), Lombardi Blueprint
(acquired by IBM), DimDim (acquired by Salesforce.com), and, in the last
couple of weeks, Google Offers, Hotel Finder, and Web Fonts.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to