I've been messing around with GWT lately and while I've got a lot of first (and very positive) impressions, the very first thing I wanted to remember is how I would address the following "negatives". I've heard and seen these comments floating around on the web and over coffee. So here we go:
I'm pretty certain that this is the oldest argument against any improvement that man has encountered. That "wheel" thing is for lazy walkers. That "sail" thing is for lazy rowers. That "C" language thing is for lazy assembly language programmers...and on and on. Suffice it to say, I firmly believe that GWT is hardly for lazy programmers. GWT doesn't code itself. The infamous self-coding computer is not at hand. What GWT does is allows a programmer to write fairly complex client-side code, intended to be executed by the ubiquitous Internet browser, in the Java language. GWT compiles it down to the language of the container and all artifacts of Java are removed. GWT is no more for lazy programmers than any other language, Java or otherwise. Very few of us write our code in Intel Assembler 80x86. We use libraries to make development easier. So if GWT == lazy programming, the All Languages == lazy programming...because real men (and women) would program in bits and bytes. And we most definitely do not.
GWT insulates the developer from the merger of HTML and Javascript, replacing it with a implementation completely in Java. Knowledge of the DOM is still necessary, if you want to use CSS (which GWT allows and thrives doing...). Last time I checked, Java can be a pretty tough language to master, so it's hardly the stuff of lazy people.
I really think this argument is, if I distilled it out and run it through the Universal Translator, is "We are masters at Javascript & HTML and we've worked hard at this and we don't want anyone else to threaten our existence." OK, maybe that's a little harsh, but the DHTML guy has for many years been the poor stepchild in the land of the Overlords of the Middle Tier, you the "real programmers". And maybe they're trying to exact a little revenge. I feel I'm very capable of speaking on this because I consider myself one of those DHTML guys that would argue feverishly that "Javascript is too a real language" and I've written (true story) hundreds of thousands of lines of Javascript in the last 8 years or so.
A back story that's relevant is that I mostly cut my teeth in this game doing VB...and that too was a "language for lazy people...as it practically did everything for you." Real men used C++ or something else. But VB, serious VB had just as many big time features that I had to memorize and dig into....COM, COM+, MTS, MSMQ...all that stuff. After I built my DLL/EXE out of that "toy" language, the rest of the world had to treat it like what it was. The fact that I was able to develop the solutions faster had as much to do with VB's IDE as it did the language itself. In VB, I didn't worry about pointers, or memory addresses, none of that "real" programming stuff. And that made me, and thousands of other developers more productive, and that's what makes the world go 'round.
But what is there in DHTML that GWT prevents me from worrying about? Still have to bind events to visual elements. Still have to lay out and style controls and talk to the server and work with the user...just doing it with a different language. What I don't have to do is worry about the variety of browsers, don't have to mess with back-button logistics, AJAX calls and the like. And if my backend is Java based, they've got a nifty serialization that makes it feel like RMI between client and server. Admittedly, a good client side library (and there are a bunch of good ones) have all this and more, so that's a push (maybe not the RMI...). But there's one thing that traditional DHTML doesn't have, and that's world class, year 2007 style IDE support.
When I was scratching out my VB argument, I said that VB's "success" had as much to do with its IDE as anything. And I think that's the one thing that the argument against GWT is seriously missing. And to understand why, I'm going to make some gross assumptions about those who are in opposition to GWT --the typical DHTML guy. This guy came up through the ranks as the web guy. The guy who tossed together those little web page/HTML thingies. The guy who knew what a lot of the Apache/IIS settings meant, but not all of them. Some are serious development types, with their CS degrees proudly displayed, but a lot are just hard working stiffs who taught themselves what they know. When the web shifted to a richer, form-posting CGI world, a lot came with it. They learned the intricacies of the Response/Request objects. When we shifted to XMLHTTP, a few moved at that point, then the rest followed when the same technology was relabeled AJAX -- 6 years later! By then, the very elite DHTML guy was doing amazing things with Javascript, knowing the inner-workings of the DOM and how to make HTML/DOM/JS/CSS literally sing. And they do this with some sort of glorified text editor. That's not a derogatory statement, most development is done with one. And you learn to live with it. You probably use an debug output logging window gadget, either of your own design or scavenged from the web. You've become one with "View Source" and its much more helpful descendant, Firebug. And you are an absolute pro typing "alert("current value: " + something);"...and remembering to remove all this before you release. Again, gross assumptions and profiling going on here... But if you've developed in a modern IDE, like Eclipse or Visual Studio, and your language is fully understood by the IDE...life is truly amazing.
Setting breakpoints and watches in source, stepping through executing code, asserting new values...these are truly big time programming tools. Code assist, code complete, intelli-help, little red underlines when you're code isn't typed correctly...if you've never had the pleasure, you're truly missing out. And what makes GWT so compelling to me, is it's complete integration with Eclipse and its on-the-fly compilation...you type myObject.doStuff() and it'll point out to you that your class for myObject doesn't have a doStuff() method...what should we do? I know Visual Studio has this these days, it's just been a couple of years since I've used it. A lazy programmer...maybe. But much more productive and less prone to run-time errors.
OK, I'll bite. Why not? Seriously, if someone tosses that out, I want to know why. Just like what you believe in religion or what football team you follow, there had better be some meat behind this, or it's just rhetorical rumblings of some sort. I had a great talk with my dad about this topic...he didn't really know it though. He was in the work place (the 60's) when the shift was from everybody doing assembler to some people using a higher order language. His story to me was that there were legions of skilled programmers, completely proficient in assembler at that time. But the promise of the higher order languages was too tempting: Developers could be more productive and developers could be mere mortals, or as it turned out, developers could focus their attention to other details like performance, documentation, internationalization & library development. I think that's what GWT provides. A UI developer can be more productive (see above) in producing stable, performant and supportable code. And that should be the goal for every organization that has development going on. If it's my business, I want to maximize my dollars by having developers as productive as possible and have a code base that can withstand the inevitable ebb and flow of people and abilities. And I still want it to work well, both in performance and solving the problem at hand. The hard-core Javascript developer is capable of producing this with the standard DHTML stack...and now a more Java-centric developer can do the same thing. But as I stated before, I think the Java language construct is more conducive to productivity.
GWT is for lazy programmers.
I'm pretty certain that this is the oldest argument against any improvement that man has encountered. That "wheel" thing is for lazy walkers. That "sail" thing is for lazy rowers. That "C" language thing is for lazy assembly language programmers...and on and on. Suffice it to say, I firmly believe that GWT is hardly for lazy programmers. GWT doesn't code itself. The infamous self-coding computer is not at hand. What GWT does is allows a programmer to write fairly complex client-side code, intended to be executed by the ubiquitous Internet browser, in the Java language. GWT compiles it down to the language of the container and all artifacts of Java are removed. GWT is no more for lazy programmers than any other language, Java or otherwise. Very few of us write our code in Intel Assembler 80x86. We use libraries to make development easier. So if GWT == lazy programming, the All Languages == lazy programming...because real men (and women) would program in bits and bytes. And we most definitely do not.
GWT insulates the developer from the merger of HTML and Javascript, replacing it with a implementation completely in Java. Knowledge of the DOM is still necessary, if you want to use CSS (which GWT allows and thrives doing...). Last time I checked, Java can be a pretty tough language to master, so it's hardly the stuff of lazy people.
I really think this argument is, if I distilled it out and run it through the Universal Translator, is "We are masters at Javascript & HTML and we've worked hard at this and we don't want anyone else to threaten our existence." OK, maybe that's a little harsh, but the DHTML guy has for many years been the poor stepchild in the land of the Overlords of the Middle Tier, you the "real programmers". And maybe they're trying to exact a little revenge. I feel I'm very capable of speaking on this because I consider myself one of those DHTML guys that would argue feverishly that "Javascript is too a real language" and I've written (true story) hundreds of thousands of lines of Javascript in the last 8 years or so.
A back story that's relevant is that I mostly cut my teeth in this game doing VB...and that too was a "language for lazy people...as it practically did everything for you." Real men used C++ or something else. But VB, serious VB had just as many big time features that I had to memorize and dig into....COM, COM+, MTS, MSMQ...all that stuff. After I built my DLL/EXE out of that "toy" language, the rest of the world had to treat it like what it was. The fact that I was able to develop the solutions faster had as much to do with VB's IDE as it did the language itself. In VB, I didn't worry about pointers, or memory addresses, none of that "real" programming stuff. And that made me, and thousands of other developers more productive, and that's what makes the world go 'round.
But what is there in DHTML that GWT prevents me from worrying about? Still have to bind events to visual elements. Still have to lay out and style controls and talk to the server and work with the user...just doing it with a different language. What I don't have to do is worry about the variety of browsers, don't have to mess with back-button logistics, AJAX calls and the like. And if my backend is Java based, they've got a nifty serialization that makes it feel like RMI between client and server. Admittedly, a good client side library (and there are a bunch of good ones) have all this and more, so that's a push (maybe not the RMI...). But there's one thing that traditional DHTML doesn't have, and that's world class, year 2007 style IDE support.
When I was scratching out my VB argument, I said that VB's "success" had as much to do with its IDE as anything. And I think that's the one thing that the argument against GWT is seriously missing. And to understand why, I'm going to make some gross assumptions about those who are in opposition to GWT --the typical DHTML guy. This guy came up through the ranks as the web guy. The guy who tossed together those little web page/HTML thingies. The guy who knew what a lot of the Apache/IIS settings meant, but not all of them. Some are serious development types, with their CS degrees proudly displayed, but a lot are just hard working stiffs who taught themselves what they know. When the web shifted to a richer, form-posting CGI world, a lot came with it. They learned the intricacies of the Response/Request objects. When we shifted to XMLHTTP, a few moved at that point, then the rest followed when the same technology was relabeled AJAX -- 6 years later! By then, the very elite DHTML guy was doing amazing things with Javascript, knowing the inner-workings of the DOM and how to make HTML/DOM/JS/CSS literally sing. And they do this with some sort of glorified text editor. That's not a derogatory statement, most development is done with one. And you learn to live with it. You probably use an debug output logging window gadget, either of your own design or scavenged from the web. You've become one with "View Source" and its much more helpful descendant, Firebug. And you are an absolute pro typing "alert("current value: " + something);"...and remembering to remove all this before you release. Again, gross assumptions and profiling going on here... But if you've developed in a modern IDE, like Eclipse or Visual Studio, and your language is fully understood by the IDE...life is truly amazing.
Setting breakpoints and watches in source, stepping through executing code, asserting new values...these are truly big time programming tools. Code assist, code complete, intelli-help, little red underlines when you're code isn't typed correctly...if you've never had the pleasure, you're truly missing out. And what makes GWT so compelling to me, is it's complete integration with Eclipse and its on-the-fly compilation...you type myObject.doStuff() and it'll point out to you that your class for myObject doesn't have a doStuff() method...what should we do? I know Visual Studio has this these days, it's just been a couple of years since I've used it. A lazy programmer...maybe. But much more productive and less prone to run-time errors.
Javascript shouldn't be treated like assembler
OK, I'll bite. Why not? Seriously, if someone tosses that out, I want to know why. Just like what you believe in religion or what football team you follow, there had better be some meat behind this, or it's just rhetorical rumblings of some sort. I had a great talk with my dad about this topic...he didn't really know it though. He was in the work place (the 60's) when the shift was from everybody doing assembler to some people using a higher order language. His story to me was that there were legions of skilled programmers, completely proficient in assembler at that time. But the promise of the higher order languages was too tempting: Developers could be more productive and developers could be mere mortals, or as it turned out, developers could focus their attention to other details like performance, documentation, internationalization & library development. I think that's what GWT provides. A UI developer can be more productive (see above) in producing stable, performant and supportable code. And that should be the goal for every organization that has development going on. If it's my business, I want to maximize my dollars by having developers as productive as possible and have a code base that can withstand the inevitable ebb and flow of people and abilities. And I still want it to work well, both in performance and solving the problem at hand. The hard-core Javascript developer is capable of producing this with the standard DHTML stack...and now a more Java-centric developer can do the same thing. But as I stated before, I think the Java language construct is more conducive to productivity.