Friday 12 August 2011

Technology Radar

After reading the Thoughtworks Technology Radar for July I could not help dropping a few lines to praise this statement:

GWT is a reasonable implementation of a poor
architectural choice. GWT attempts to hide many of
the details of the web as a platform by creating desktop
metaphors
in Java and generating JavaScript code to
implement them. First, in many ways, JavaScript is
more powerful and expressive than Java, so we
suspect that the generation is going in the wrong
direction
. Secondly, it is impossible to hide a complex
abstraction difference like that from event-driven
desktop to stateless-web without leaky abstraction
headaches eventually popping up
. Third, it suffers from
the same shortcomings of many elaborate frameworks,
where building simple, aligned applications is quick and
easy, building more sophisticated but not supported
functionality is possible but difficult, and building
the level of sophistication required by any non-trivial
application becomes either impossible or so difficult
it isn’t reasonable.


Wow, even never having done any development with GWT I think I can fully endorse those claims without fear of being wrong. When I first heard of GWT some years ago I thought it was a huge step back.
My boss in one of my first development projects was a real "guru", a visionary that had developed an impressive RIA framework in the early 2000's, using tons of beautiful Object Oriented JavaScript (both on the client and on the classic ASP server), CSS, Active X (it was for intranet applications that only needed to run on IE), an excellent debug console and tons of XHR (at that time JSON was almost unknown, so it was sending/receiving needlessly verbose XML). The first versions even used iFrames instead of XHR.
Well, I'm telling all this because thanks to that (and to an old o'reilly JavaScript book where I first read about prototypes) I've been pretty aware of the power of JavaScript and client side coding from rather early, and that's why GWT smelled like crap to me since the first moment.
Translating Java to JavaScript seemed absolutely ridiculous to me (I could even say insulting), and it can only be justified by wanting to do life easy to sloppy programmers that are not willing to learn a new language and paradigm. It appears to me a terrible mistake, similar to the error of keeping VB around by morphing it into VB.Net, instead of forcing developers to learn the beauty of C#...

The idea of hiding the Web particularities under a "desktop metaphor" was first implemented in Asp.Net WebForms, and I would say that with terrible results (don't get me wrong, it can be OK for some kind of applications, but not for the kind of applications that we need today, well, hopefully now we have the almighty Asp.Net MVC) that were hardly improved with the addition of "Update panels". Shit, I remember the pain of trying to make some basic JavaScript DOM manipulation in an Asp.Net 2.0 Web application (with tons of update panels, puff...) that we developed 4 years ago... the hacks that we had to devise to work around all the limitations imposed by "the Web as the Desktop" nightmare...

Web Developers have had excellent DOM, Ajax, effects, "language enrichment" libraries since a long while (jQuery, mootools, dojo...), so what we now need are JavaScript frameworks pushing and helping us to write more maintainable JavaScript intensive applications. It seems like backbone.js and JavaScriptMVC could be good steps in that direction. Unfortunately I haven't had a chance to play a bit with them, but I'm longing to get my hands dirty with them :-)

No comments:

Post a Comment