Bunk and bunk. It reminds me of when some "Javascript Engineer" consultants 
sent out an email crapping all over GWT several years ago at a major global 
bank I worked for that used GWT as their standard UI toolkit. They cited a 
whole bushel of straw man and red herring arguments while only highlighted 
their complete lack of understanding of GWT. I fear this article was in a 
similar vein.

 

> From a practical standpoint this doesn't work well. 
> 1. Using code-gen to produce the artifacts is time consuming, artificially 
> extending build times and requiring manual changes to obtain optimal 
> package layout.
>

Funny. The pure JS community is creating their own compilers these days... 
odd coincidence. And also, many are using the defacto Closure Compiler, 
which GWT uses too, but you don't get the same depth of minification, 
obfuscation and browser specific packaging as you do when using it in 
conjunction with the GWT compiler. For me, on a moderately complex app, my 
code/compile/test iteration cycle time is 8 seconds. Sure beats JSP. And, 
if you're a seasoned professional, you can batch a whole number of code 
changes into that 8s vacation.

 

> 2. If the JavaScript doesn't behave exactly as you want you will have to 
> hack the generated code.
>

I've never hacked the obfuscated/compiled GWT output. That sounds pretty 
painful. Why would anyone do that?

There have been few times for me when this has been a problem in 3 years. 
Usually it's a matter of either (1) an incomplete/faulty API implementation 
by a browser or (2) initialization timing problems on element injection 
into the DOM. Here you'd usually just not use the broken browser API for 
(1) and use some deferred scheduler calls for, though you'd have the same 
problem in vanilla JS (2). If you really must "hack" then you can pop out 
some JSNI, but I'd say under 0.5% of my GWT app code is JSNI.
 

3. Using Java to generate JavaScript means that you can’t take direct 
> advantage of the powerful features of JavaScript or numerous libraries such 
> as JQuery. Finally, the JUnit support is quite limited, for example code 
> using reflection cannot be tested.


"Powerful features of JS"? I hope everyone's technical novice meters were 
set off by that sentence. When you can't articulate why a technology is 
superior in technical terms, then you don't know what you're talking about. 
If JS was a tractor engine, then you could claim it put out more watts than 
another engine, thus making it more "powerful." But, it's not an engine.

So what are we missing? Native prototypes, expandos, arrays, type cohesion 
and all numeric values as doubles? Are we missing out on the general 
maelstrom of namespace conflicts in a given Window? Are we missing out on a 
JS HTML5 spec that's been a draft for 6 years? Are we missing out on 
sacrificing our lives for IE interoperability? I'd argue not. We're being 
insulted from a language created to validate form inputs 20 years ago and 
implemented inconsistently on many browsers. But, if you want to use 
"numerous libraries such as JQuery" you actually can use them, either 
wrapped or natively in from JSNI.


So, FUD I'm afraid. I can't help but see down the road 4 years to when many 
*hot* JS libs are defunct and ACME's sales app can no longer run, despite 
the trivial functionality provided by XYZ JS that's used pervasively across 
their application and no longer works with IE 14. If it was GWT, they could 
just update their GWT compiler version number in Maven and get a cup of 
coffee while it builds. Run their regression against it and get ready to 
ship for IE 14 after any needed tweaks. Sadly technical management never 
gets compensated 4 years later for the $1M rewrite that didn't happen.


Sincerely,
Joseph

 

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Reply via email to