GWT is the present of web development

Logo GWTI’ve read a few articles by people who didn’t like GWT, but usually I don’t care to reply because it requires a lot of time to do it properly. However, today I came across this article on dzone: Lost in Translation or Why GWT Isn’t the Future of Web Development.

This one was troubling because it made good points on the way, some that I can’t agree more with (like the quality of Ext-GWT…) but it comes to a completely biased conclusion about GWT. So I took some time and wrote a reply

One thought on “GWT is the present of web development

  1. Here’s a copy of my reply in case it gets lost somehow:

    “GWT isn’t about leveraging Java programmers, it’s about leveraging Java tools. Whatever you think of Java, it has great IDEs with a whole lot of tools that help you write code faster, refactor painlessly, debug efficiently. JavaScript IDEs are no match.

    You say that GWT fools Java developers into thinking they don’t need to learn JavaScript. Actually, I am a living proof that GWT lets Java developers write AJAX applications without needing to learn a single line of JavaScript. And I’ve been working with GWT for 2 years building serious business-critical apps.

    Oh of course the generated JavaScript code might not use all language idioms and might not be as efficient as code hand-written by a very experienced JavaScript programmer, but so what? it’s probably way more efficient than code written by most actual JavaScript programmers. If you need that extra bit of performance, then I’ll agree that you need to write JavaScript. Just like you need to write assembly code if you really need to write the fastest native application. But otherwise, would you reject using a high-level language over assembly, just because you’re not using all the assembly language idioms? In both cases (GWT to JavaScript and high-level language to assembly), it’s the compiler’s job to ensure that target language idioms are used appropriately. Not being able to use those idioms in the source language doesn’t mean the compiler can’t use them.

    It’s really inappropriate to judge GWT by the visual appeal of the built-in widgets. They are meant to provide minimalistic functional components, not be the ultimate widget set. I’m working with Ext-GWT (and I share your views about it), but despite its horrible API, the widgets are very nice to use. Again, don’t blame GWT for the lack of genericity in Ext-GWT or the design flaws of its API.

    GWT is very nice to work with in development mode, because what you are actually compiling and testing is a native Java application, so your IDE most probably does the incremantal compilation, all you have to do after you’ve made changes is hit the “refresh” button in the hosted mode window! So who cares that GWT compilations for web mode are long, as long as your app behaves correctly in dev mode, it will behave the same in web mode. The compilation should not be done on the developer’s workstation but on the integration server, except maybe once in a while to check how web mode performs compared to dev mode. If you’re constantly compiling for web mode, you’re doing something wrong.

    Layers: again I don’t see what this point has to do with GWT. If you think that using a scripted language on the client makes it a good idea to send server-side business objects over the wire, you should reconsider. Server-side manipulates business objects, client-side manipulates UI objects; they don’t abstract the same concepts. Once again, you’re blaming GWT for bad design.

    I think there is definitely a place for scripted languages in web development, but I will argue that as of today, GWT is the only sensible way to approach a large-scale project involving an AJAX front-end.”

Leave a Reply

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