GWT is not the future but the present of web development

I just read an interesting blog articles about „is GWT the future of web development or not„. I find the titles quite funny, because I really don’t believe that it was no ones intention to forecast the future, so the real question is – is GWT a good approach for present web development?

There is actually too much fuss about static or dynamic language. The best language is still the language I know best. I feel quite at home with Java and Eclipse – I won’t be any more productive in any other language so soon. If you are telling me that one can do things faster with Grails & Co. you might have a point (I really don’t know), but then we are talking about (web) frameworks and not about the language. I have my roots in Perl programming and I know exactly why I like type safety, but this again is a very personal statement.

Personally speaking, leveraging Java Programmers means really a lot to me. It is not only Eclipse and Java. It is checkstyle, findbugs, unit testing, build infrastructure. I have appreciated reading the GOF patterns, I loved Effective Java and I still have to chuckle when I think of the bad smells in Refactoring (which I somehow know all by personal history). When I do code in Java I mostly do it by consciousness and not by copy and paste from some sites like in my early days in development. Is a matter of fact, I do have something to leverage and it really means something to me.

But wait, let’t just don’t forget that GWT does something really tricky. It is not imposing some Java GUI component model on Javascript. They never left sight of what can be done with Javascript and can’t. It is not like RAP that tries put the Eclipse workbench on the browser, they are just being HTML and Javascript. And this is good and bad. It is good because it is about generating efficient Javascript, and bad because HTML looks ugly without lots of makeup.

If you are looking for eye candy in web development, don’t wast your time with GWT. And if you start doing SmartClient or GXT just know that you are not really leveraging GWT, thats just using GWTs infrastructure but nothing more.

If you are looking for software engineering in web development, take a closer look at GWT.

And yes, the GWT compilation is brutal. That’s why we have the developer modus (formerly known as hosted modus) – it starts fast and I keep it running. Simply refreshing the browser gives me the refreshed code, refreshing the jetty server gives me the changes in the backend. With OOPHM (out of process hosted modus) GWT looses the tight coupling to the only one browser on each OS by doing hosted modus inside-out. Google for it or try it out on your machine, works very good here. And, btw, I do have good monitor, a good chair and a fast computer. I mean, this is my day-to-day job.

I don’t know if scripting is the future, but I know it is the present when we speak of web development. Browser do speak  javascript and this won’t change in the near future, I mean, it is even getting worse (or better, you name it) with HTML 5, where we will be able to do 2D and video and much more just in javascript.

And when it comes to javascript in the browser, I don’t see any better approach then GWT at the moment.

Maturity? GWT is rock stable. It is more a compiler and does not really give me much runtime dependencies. We now have AdWords and Google Wave to showcase how far we can come if we have the knowledge and the resources.

And no, there is no eye candy.

If you are going down the GWT road, please have a look at the GWT Architectural best practices. If you like Spring (as I do), please have a look on how to use your Spring backend with GWT-dispatch (command pattern based RPC approach for GWT).


Joel has commented on the ranting post and it is hard to find it on the very long list of comments. That’s why I want to quote it here:

It’s unfortunate to see another long rant based on the same misunderstandings that we’ve seen from the day we released GWT. Very briefly, here are the major issues I see:

1. I don’t like Java, because Java programmers write reams of unnecessary abstraction.
We largely agree on this point (speaking for myself, at least, not everyone at Google). J2EE is a monstrosity, as is whatever library led to RequestBuilderFactoryFactory. This has precisely squat to do with Java the language.

2. Translating Java to Javascript necessarily leads to bad code, because some things can’t be translated well.
This is, in some sense, true. I really wish Java had a first-class function/method object (C# delegates would be fine). I wish Enum weren’t so damned heavy (we’re working on that). But the things that aren’t present in Java, that would be useful when translating to Javascript, probably account for <5% of the code we generate. So it’s irritating but largely irrelevant.

3. Compilation times take too long.
I hate them too. So what? But if you’re not using hosted (development) mode 99% of the time, you’re either doing something wrong, or you fall into one of a few special cases (e.g., new mobile libraries) that we’re working to address. Development mode gives you basically the standard edit/refresh cycle you get with Javascript, except that the compiler, generators, and other tools all get a chance to do work and catch errors.
Also, if you think you can get away without some sort of compilation process for a large Javascript application, you’re unfortunately mistaken. Badly. You can’t just concatenate a few hundred thousand lines of Javascript, strip out the comments, and hope for the best. You’ll end up with a monstrosity of several megabytes, even for a medium-sized app.

4. The widgets suck.
Fair enough. Hell, I wrote half of them, and don’t entirely disagree. Go write some that don’t. Oh, and when you run off to talk about how much Ext sucks, realize that you’re saying that Ext-JS sucks as well. Neither is the fastest library in the world, but they are very complete and cover a huge variety of use-cases. They made a very different set of tradeoffs than we did, but they’re a legitimate set of tradeoffs, and appeal greatly to enterprise developers that need to get a lot of UI built quickly.

5. Not all applications are Gmail.
No kidding. If I were a real pedant, I would point out that this is a tautology. But yes — if you’re building a simple „page at a time“ app and need to add a little script to it, by all means use JQuery or whatever you feel like. That’s appropriate. Use the right tool for the job.

GWT was built to solve a specific set of problems, and we took what we believe are the right set of decisions to do so. Plenty remains to be done, and we continue to work on it. I wrote up a clarification on several of these points some time ago:
I hope this proves helpful to some.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darĂĽber, wie deine Kommentardaten verarbeitet werden.