@ayende You ought to try Mercurial. in reply to ayende 1 week ago
03
Feb

Published

My blog entry on Volta, GWT and leaky abstractions has been reproduced in the .NET Developers’ Journal.

This was a particularly interesting post because a lot of people are pretty impressed with Volta, and on the face of it, I was pointing out what I saw as its potential shortcomings. It has also attracted some comments from fairly accomplished developers — Bruce Johnson of Google’s GWT team, and Mats Helander, who wrote one of the first O/R mappers for the .net framework. However, while I may have come across a bit negatively, my opinion is not actually so much an anti-Volta/GWT/RJS one as a pro-JavaScript one. Since I started taking JavaScript seriously a year or so ago, I’ve really started to appreciate it, and to be honest, I think that developers who hide from it altogether behind abstraction layers of whatever nature are really losing out.

I’ve also had an e-mail from a journalist asking me for my opinion on MySpace for an article that she’s writing. I’m not sure I’m the best person to ask on that one to be honest: my experience of MySpace is pretty much limited to opening an account, discovering it doesn’t work with Windows Live Writer, closing it again, getting spammed, and experiencing all the yuk-that-is-gross reactions that any respectable, standards compliant, XHTML addicted web developer experiences on seeing your average profile page with gratuitous background images, animated GIFs, thrash metal background music, and broken rendering in Firefox.

It’s interesting where blogging can take you…

11
Dec

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.