Why I don’t like the Google Web Toolkit
Just wrapped up the first day of the Rich Web Experience which wound up with a discussion between Stuart Halloway, Alex Russell, and myself about Google Web Toolkit. I’ve never been a fan of treating JavaScript like Assembly or some other low-level language, as if it’s something to be compiled down to versus truly understanding, which is exactly what GWT does.
Alex made the point that GWT does what it does very well, to which I really can’t argue. It does a good job of providing an interface for Java developers to write JavaScript and handles a lot of the cross-browser ugliness in a completely transparent way. My problem is really that this encourages people to use Java instead of learning JavaScript.
A problem in the industry right now is the lack of good JavaScript developers. Since it’s easier to find Java developers, it makes sense to take advantage of that. GWT leverages the vastly larger pool of Java developers and uses them to write JavaScript, which is an interesting approach to the issue. The problem with this approach is that it doesn’t solve the fundamental problem: the lack of good JavaScript developers. The same number of JavaScript developers exist but the amount of people outputting JavaScript has increased…this doesn’t seem right to me.
In order to create more good JavaScript developers, we need to convince good programmers to learn it. We shouldn’t be giving up the fight and accepting that the current set of good JavaScript developers are all that we will ever have. We, as the JavaScript developers of today, should be encouraging other to learn how to do what we do so that the pool of good JavaScript developers increases.
GWT is, I believe, an intriguing proof-of-concept and a unique way to do things. I find it impressive in a purely academic sense but I would never use it for anything I work on (and I’d probably revolt if someone tried to force me down that path).
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.
8 Comments
I (a java developer) agree. We may not be the norm, but in my circles, the trend is actually in the opposite direction. We’d rather write in a more dynamic language (ruby/javascript) and feel chained down when we go back to java. Java is still near and dear to me, but sometimes its appropriate to cut the chains. I don’t understand the fear of actually learning the language. I agree with the pragmatic guys, its good for you: http://www.pragmaticprogrammer.com/loty/
James Estes on September 7th, 2007 at 3:35 am
It is probably a general principal that the higher level of abstraction provided by a framework is, the more intimate knowledge of its inner workings required to be productive with the framework. So maybe frameworks like GWT still promote an increase in a number of good JavaScript developers, though indirectly
?
Alexei on September 7th, 2007 at 6:21 am
I’ve been waiting for this post for a long time…you know I have.
To all who read this blog, a disclosure: I love Javascript. I have no issue with scripting. No issue with dynamic, loosely-typed languages…I love ‘em! I teach high school (on the side, my day job is a software engineer), and I teach the kids Javascript. I consider myself quite skilled in Javascript, working in it heavily for the last 9 years or so. Having said all that: I think GWT is terrific. To an admittedly narrow band, it’s great. Here’s what I mean by that….
I work in a shop that has morphed from multiple languages (Java, C#, VB6, Delphi, VBScript ASP pages, C++, & a ton of Javascript and XSLT and more) to predominantly Java and Javascript. Obviously, we do our browser/client side work in Javascript and the rest, server side and heavier clients are all Java. So we have to have the "web guys" and the "Java guys"…of which I’ve been classified as a web guy. But what I really am is the "front end/UI guy"…I’ve done a ton of work in the last couple of years working with SWT, a Java based heavier client framework. But the code I write there is completely understandable and supportable by the rest of the team…it’s Java. So GWT would allow us (a large development group for an international financial organization) to have one language: Java. The code that I write for web pages would be supportable by a Java developer. Now admittedly, I’m not thrilled with the prospect of somebody who’s not really focussed on the user to be putting together UI’s..but that’s another argument really. Nor do I think that Javascript is all that tough to figure out for a decent developer, but there’s a barrier. The cost/management advantages to language homogeny in a development group can’t be under sold…and that’s worth a lot to the bottom line of a development group.
So that’s point one (IMHO)…language homogeny is good. But what else ya got? How about the terrific IDE support that Java has and that I’m still not seeing in the Javascript world. It’s easy to miss this: as a Javascript developer, I’ve gotten used to the main tools: a good editor (I prefer UltraEdit myself), a couple of home grown Debug.Out type of libraries, Firebug is sweet (but we’re an IE shop, sadly) and a couple of other things. Compare that to GWT’s support inside of Eclipse…and it’s night and day. Just typing code in an Eclipse editor is a thing of beauty: it’s always compiling so you get support for method signatures and all that…like a good modern IDE does for you. Code completion, library introspection, incompatibilities…everything you need at "design" time (actually code-writing time…). And then at run-time/debug-time? Even better. Set a breakpoint in your GWT/Java code, and start your app, and it breaks right at the line, letting you step and watch and do all the nifty debugging stuff you’d expect. I’ll admit that I haven’t seen everything…but I haven’t seen anything close to this in the traditional Javascript world (Aptana is nice, as is the latest Visual Studio .Net…but still not completely there). In my old age (been doing this since the early 80′s guys), I need all the help I can get. And development like this is more productive, and that saves my company money.
They (the GWT guys) like to trot out the AJAX framework, the widgets, stuff like that… I gotta admit, that’s a bit of a push in my books. You can get AJAX frameworks from a lot of places that are just as easy, same with widgets. I do like the browser compatibility advantages and the back button support that you get from GWT..they’re nicely done and all, but you really have to buy into the whole GWT experience to feel it. That said, if you’ve got a Java middle tier, and you want to serialize your value objects to the client…GWT’s RPC is amazing. Actually it’s not amazing: it looks just like RMI..what it’s doing under the cover with XMLHTTP and all is the amazing part.
A lot is made of the "Javascript as Assembler" angle. I think that’s a moot point. I used to know a lot of very talented ASM guys. That’s how things had to get done. And there are still a number of them around, doing some amazing stuff. But now we write our code in higher level languages…like Javascript, like Java. So abstracting up a level is a typical and normal progression of things. And I remember back when I was working at a place with a lot assembly language stuff…and we were moving to C. Same arguments: Assembly is easy and it’s dumb to write things in a higher language like C just to have a compiler make Assembly out of it. The more things change, the more they stay the same. I will say this: learning assembly (and I did), made me a better C programmer. Knowing C & C++ made me a better Java developer…and Javascript and VB and C# and even Ruby developer (I’m messing around there right now…) So I think learning how GWT works, and how Javascript works is a good thing…but I can appreciate how more productive you can be in GWT.
I would expect you (Nicholas) to be very pro Javascript: you are arguably one of the top Javascript developers around. You work for a joint universally renowned in the Javascript development zone. And to sound completely circular here, if Javascript had the same IDE support as GWT does in Java…I’d be more inclined to shut up. To be fair: I don’t for a minute think GWT is going to be the norm or dominate the market. If you’re a .Net type of developer, you’re not going to deal with it. Like you, the rest of the DHTML web/Javascript guys are not going to either…there’s way to much time in their development of the craft. But in a narrow band of Java shops that value language/technology homogeny, that have seen the advantages that development in Eclipse can bring, GWT is a revolutionary type of product. As a premier Javascript developer, maybe you aren’t exposed to the "normal" web developer type. I’m going on a stereotype bender here; but here’s what a lot of them look like: very average Javascript skills…some are still doing old school ASP or PHP with form posts. Javascript is mostly for limited client side validation and for "effects" that were scraped from some web page. The real work is done in the middle. While it’s gotten more predominant in the last couple of years, the true Javascript developer is still a bit of a rare bird.
This is more a random series of thoughts rather than a concise (obviously) treatise on GWT. And I’d expect a revolt from you of all people if you were forced to use GWT!
Mike Shaffer on September 7th, 2007 at 9:00 am
so the ORM features in Rails, Hibernate and Symfony abstract the need to know advanced SQL. Is that bad as well? GWT is a tool/framework to allow programmers to build faster.
I do agree that it’s worthwhile for developers to understand the fully ALL the languages that comprise his/her webapp (it really helps debugging multi-tier applications).
Wally Punsapy on September 7th, 2007 at 2:14 pm
@Mike -
To a couple of your points:
- Language hegemony: Could the same argument be made in favor of ditching SQL and DB developers for a Java-based ORM? Also, I think you too quickly dismiss the value of UI specialists. Solid developers who have a good instinct for design and interaction are hard to come by indeed, and GWT makes it all too tempting for management to task middle-tier Java developers with little or no UI sense to writing the front end. Most likely, with disastrous consequences.
-Development tools for JavaScript: I write almost exclusively front-end (JavaScript, HTML, CSS) code at work, and Eclipse is my editor of choice. Have you taken a look at some of the excellent front-end plugins available for Eclipse? Take a look at aptana (http://www.aptana.com/ – which includes an integrated version of Firebug that allows Eclipse debugging and XHR monitoring, also includes JSDoc support, code completion, and workspace library configuration) or JSEclipse (http://www.interaktonline.com/Products/Eclipse/JSEclipse/Installation-Update/). Both of these plugins offer all or nearly all of the IDE features you’re missing.
- JavaScript distribution – Rhino on Rails and several other efforts (even at Google!) are making JavaScript an increasing reality on the server as well as the client. (And no, not just on ASP pages.)
You mentioned that you’re in an IE shop; you should STILL be developing on Firefox first, then debugging on IE. Even if exactly 0 of your users are using IE, by virtue of Firebug, your productivity on Firefox will be greater even taking into account the extra work to bridge two browsers.
Ultimately, a lot of the arguments I’ve heard in support of GWT turn out to have less and less merit the more one investigates the actual state of JavaScript development.
David Golightly on September 7th, 2007 at 2:25 pm
oops:
– exactly 0 of your users are using IE
++ exactly 0 of your users are using anything but IE
David Golightly on September 7th, 2007 at 2:32 pm
I’m glad this has stirred up some interesting discussion. I’m not saying GWT is of no use whatsoever. My point is that it doesn’t solve the problem of not having enough good JavaScript developers. The problem that it does solve is not having enough people who output JavaScript…and it solves that problem very well, by leveraging the already large mass of Java developers and enabling them to write JavaScript without needing to actually learn it.
My concern is, and will always be, how to get more JavaScript developers out there. The path to this outcome is not to have people stop writing JavaScript, it’s to get the people who aren’t writing it to start.
@Mike – I have been exposed to the normal web developer type in my years as a software engineer. My belief is that anyone who can learn one programming language can learn any programming language, it whether or not they want to put in the effort that makes them particularly good at that language. I don’t like that GWT encourages people not to look behind the curtain and to trust the great voice from beyond that says he is the great and powerful Oz.
@Wally – What you’re talking about is creating interfaces to work with data, reading and writing to a source without needing to know specifics. GWT is more than a data interface, it is creating executable code in another language without transparency. At least when accessing databases, you can still query the database and ensure that things have been added, removed, or changed. With GWT, you can’t really be sure what it’s doing.
Nicholas C. Zakas on September 7th, 2007 at 9:10 pm
I believe that the problem with the lack of good JavaScript developers will be solved when demand for them will grow.
The day before yesterday I searched dice.com for web developer positions. It was a drop in the ocean of opportunities for Java developers. It is natural that I thought about learning it, because I would have less problems finding a job with this skill.
JCurtis on September 10th, 2007 at 7:10 am
Comments are automatically closed after 14 days.