+Joseph Lust.
Amen !
They simply dont get the awesomeness of GWT.
2014-08-11 18:22 GMT+02:00 Joseph Lust <lifeoflust@gmail.com>:
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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment