GWT: keep thinking in Java!

Logo GWTAs a reply to a post on asking about tips for GWT newcomers, someone answered “think in JavaScript, not in Java”. I felt I had to respond, because my experience is totally the opposite, and that’s why I would recommend GWT to anyone who wishes to write AJAX applications while continuing to think in Java (not in JavaScript).

For the record here’s my reply:

“think in JavaScript, not in Java”: I strongly disagree with that!
JavaScript plays the same role for GWT as bytecode does for plain Java: an intermediate language, generated by the compiler, and interpreted by the runtime platform.
As for HTML and CSS, it is true that it helps a lot to know them, especially when the time has come to add styling to your application. This is by design, as explained in the developer’s guide: “instead of attempting to encapsulate UI styling behind a wall of least-common-denominator APIs, GWT provides very few methods directly related to style. Rather, developers are encouraged to define styles in stylesheets that are linked to application code using style names”.
The whole point of GWT is to shield the programmer from JavaScript and let him use the Java idiomatisms and tools he is used to. I’ve been working with GWT for almost 3 years now and I have never ever felt the need to learn JavaScript. And I thank GWT for that!

JavaScript is just a means to achieve the goal, which is: to build a rich web UI. Knowing JavaScript will not help you build a good client, instead you should concentrate on writing clean and robust client code using proven techniques such as MVC, which GWT makes really easy to use (unless you’re using GXT, but that’s another story…)

4 thoughts on “GWT: keep thinking in Java!

  1. Hi, I am that “someone” 😉

    What I mean by “think in JS, not in Java” is actually, “do not ever forget that you’re doing JS, after all”. There are things that Java makes easy that are not well optimized when translated to JavaScript (String.split(), for (:) loops when using an Iterable, etc.)

    All the tips and tricks related to perfs apply as well to plain old JS than to GWT (cache accesses to object properties into a local variable –this applies to Java as well, but is more than often overlooked because there are so many other things to optimize in a desktop or server Java app that the impact of this caching is quite low compared to DB or filesystem accesses–, avoid reflows –manipulating the DOM on an “attached” subtree, manipulating an element’s style–, etc.)

    Have a look at the recent Google I/O presentations about GWT [1] and Steve Souders or Nicholas C. Zakas [2] presentations.


  2. Hi 🙂 Nice to hear from you…

    I still only partially agree… I think that most of the time you can forget you’re generating JS eventually; you only need to worry about it when it you need to get the maximum performance, just like you might turn to assembly language when you need some code to run absolutely as fast as possible.

    The promise of GWT is not to generate the absolute fastest or most optimized JS (although it already does a lot), it is to take the JS headaches out of writing AJAX apps, and it does this very effectively. And if the tradeoff is that the generated JS isn’t as optimized as a JS guru would produce, then so be it… I don’t want to depend on a JS guru anyway 🙂

    Maybe what you say applies more to people who write “low-level” code, such as widget libraries, because most of their job is to interact with the DOM. As I’m only using a widget library, I’m quite shielded from all the DOM intricacies.

  3. The problem is not the DOM, it’s how you implement your “algorithms”. See for an explanation of why the “java collections” are not a good fit and you should try to use something else. The goal is to add lightweight collections to GWT so you don’t have to “think in JS” but you’d still have to make the switch to use them (just like you have to explicitly choose to switch to for a “pure Java” project)

    1. Agreed, but once again you only have to make the switch if you are concerned about optimization. The application we are writing makes heavy use of native Java collections, and yet we haven’t found that to be a performance penalty in the compiled version so far.

Leave a Reply to olivier Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.