Volta, GWT and leaky abstractions
There’s been quite a bit of hype recently about Volta, the latest and greatest offering from Microsoft. It’s a bit like the Google Web Toolkit or RJS in Ruby on Rails, in that it allows you to write everything in C# and have it translated into JavaScript. You don’t even have to use C#—you could just as easily use VB, since it works on the compiled MSIL, converting that into JavaScript. It allows you to split your application at the lower tiers as well, automatically generating web services so that you can put, say, the user authentication part of your application on a different server to the main site.
It sounds like a good idea in theory, and no doubt it will attract quite a bit of attention from developers who do not want to have to learn yet another programming language. The main attraction of this kind of framework is for developers who are frightened off JavaScript by all the cross-browser insanities and the useless, bizarre and often totally misleading messages that Internet Explorer throws up when it encounters a JavaScript error. The old “Syntax error in line 0” syndrome. There is also the issue of testing on multiple browsers on multiple operating systems. But hey, now we can write JavaScript without writing JavaScript!
But is it really necessary?
About a year ago, I would have given an emphatic “yes” in answer to that question. However, a lot has happened in the JavaScript world in the past year and a half. We now have free virtualisation software and Intel Macs, so you can run several different operating systems—Windows XP, Windows Vista, Windows Server 2003, Linux and Mac OS X—on the same machine if you are that way inclined, making cross browser testing a whole lot easier. Firebug turns Firefox from a humble browser into a powerful debugging tool. JavaScript frameworks such as Prototype, Scriptaculous, jQuery and Dojo abstract away all the nasty cross-browser stuff, allowing you to discover just how nice a language JavaScript really is. And on top of that, they give you transitions, drag and drop, thickboxes, fade anything techniques, and a whole lot of other eye candy and cool stuff as a bonus.
I’m also rather sceptical of the whole write-language-A-in-language-B business.
Admittedly, I’ve never actually tried the Google Web Toolkit or RJS, but my guess is that while there’s undoubtedly a lot that you can do with them, I doubt if they’re the most efficient. Writing JavaScript in C# or Java or Ruby will inevitably involve a layer of abstraction, and all abstractions are, to a greater or lesser extent, leaky.
Now before you shout me down on this one, yes, I know that Prototype and jQuery are abstraction layers, and therefore may well have plenty leaks of their own. However, the point that I am making is that the process of converting between languages adds a whole further abstraction layer in addition. Making the whole thing even leakier.
At present, Volta has a lot of leaks. Late binding is not supported, for instance, which means that languages such as IronPython, IronRuby or PHP (via Phalanger) are effectively ruled out, and Visual Basic requires you to use Option Strict. This seems a bit surreal given that JavaScript itself is also a dynamically typed language, but it is a consequence of the fact that it all goes through the statically typed MSIL intermediary, and support for reflection (which is needed to simulate dynamic typing on a statically typed platform) is severely limited.
I am also sceptical of the benefit of being able to move parts of your application between the client and the server. Far from making things simpler, this could introduce a whole new can of worms if it is not carefully thought out, partly in terms of performance, particularly if you end up with a very chatty interface between them, but much more seriously, in terms of security. Maintaining state across multiple tiers is also very difficult if not impossible to abstract completely transparently, and it will be interesting to see how they tackle this problem.
However, it is probably a little unfair to knock it too much at this stage. Volta is only a technology preview and pretty experimental, so obviously some of these leaks will be patched as it matures. On the other hand, undoubtedly other leaks will remain and may even prove impossible to patch—in particular, performance will never be the same as with pure vanilla JavaScript, and download sizes will still be greater. So by all means check it out if you like, but as far as I’m concerned, if a task calls for JavaScript, JavaScript is what I intend to use.
Posted at 23:00 on 11 December 2007.
“I am also sceptical of the benefit of being able to move parts of your application between the client and the server. Far from making things simpler, this could introduce a whole new can of worms if it is not carefully thought out, partly in terms of performance, particularly if you end up with a very chatty interface between them,”
Well, the risk is certainly there, agreed. But you also have the potential to build a lot less chatty, more high performing applications.
Before, as soon as the client needed any interesting computation done it would have to call the server for this…well, at least it would if I had coded it, since wild horses couldn’t make me attempt implementing complex computations in JavaScript. Yet again.
But now I can write the computations in C# but have them execute as JavaScript on the client. This means the client won’t have to call back to the server anymore, making for a less chatty and probably more responsive app – and potentially more high performing since it can then utilize the client’s idle supercomputer instead of further overloading a poor server.
/Mats
I believe, that GWT will go being great … there is seriously no need for us to think how to let browsers execute … Lets just focus more on the logic, let the browsers world become an independent feild, an abstracted one … Let the computer do this job
Moreover, I must tell JavaScript experts that GWT and others will start making web browsers techonologies more sophisticated and harder to implement, this is mainly because GWT will become very famous soon… This is a revolution for java again … Thanks to Google …
GWT is indeed a leaky abstraction. This is the case both because (1) all abstractions leak, and (2) we designed GWT that way on purpose.
GWT aims to provide lots of leverage around the problem of building complex, portable Ajax code for browsers. But that is very intentionally not the same thing as trying to enforce some sort of idealized walled garden, pretending that it isn’t really a browser underneath. That would be hopelessly unrealistic and probably not even in the developer’s best interest. What if a hot new plug-in comes out (e.g. Google Gears)? You need to make it easy to use any browser technology directly from a GWT code base. That’s the reason for GWT’s JavaScript Native Interface (JSNI) and its special treatment of the JavaScriptObject class as a zero-overhead handle to actual JS objects.
We like to think this philosophy provides the best of both worlds: easy interop with handwritten JavaScript, yet highly optimized compiled JavaScript code. (Check out the JS code produced by the latest versions of the GWT compiler to see just how far it goes optimizing Java source.)
@Bruce: You’ve clarified a point that I think I could possibly have been a bit clearer about myself. I’m not intending to be anti-GWT/Volta/RJS here so much as pro-JavaScript. As you say, actual JavaScript objects, via JSNI or however, will help to fill in the gaps and I quite agree.
@Mats/@A_min: see my response to Bruce. While it is possible to do a lot in GWT/Volta, and perhaps most things, IMO you are doing yourselves a disservice if you hide from the raw JavaScript aspect of it altogether. The fact remains that there will be gaps and cases that it doesn’t cover where you will need to resort to JavaScript to do what you need to do. Besides, as I said, JavaScript isn’t quite the monster that we tend to think of it as being.