Microsoft architect compares Volta and Google's GWT

Is Microsoft’s “cloud programming” toolset Volta — which Microsoft released in early preview form this week — a “me-too” response to Google’s Google Web Toolkit (GWT)? I’ve seen that argument from fellow ZDNet blogger Ed Burnette and others around the Web.

I asked Microsoft Volta Architect Erik Meijer to explain, from his perspective, the similarities and differences between the two rivals’ offerings. Here’s Meijer’s take (which I edited by cutting out the code samples which Meijer provided):

Leveraging the Potential of a Common Intermediate Language

Since Volta’s release, there have been a number of questions about how Volta compares to other tools like GWT. Both Volta and the GWT aim to make Web programming easy for developers that are comfortable in contemporary object-oriented languages such as Java, or C#, VB, etc. However, comparing Volta and GWT is a little bit like comparing apples and oranges, both are a kind of fruit, yet at the same time they are completely different. For instance, the GWT is an official product that came out of beta in August this year and has been available since May 2006. Volta is an experiment that is still in its early stages. We are releasing it early so we can gather feedback from developers on the architectural directions. The focus of this release is not application performance, size, or compatibility robustness. There are also a number of significant technical differences between GWT and Volta as explained below.

Universal

From an architectural point of view, Volta facilitates a many-to-many mapping between programming languages and execution environments by leveraging the Common Intermediate Language as defined by ISO/IEC 23271:2006. The idea of using a common intermediate language to translate M source languages into N target languages dates back as far as 1958 with UNCOL (see also this). You can use any .NET language to write your application and compile it to a .NET assembly using an unmodified compiler. Volta then post-processes the generated MSIL inside the assembly based on declarative annotations in the code by automatically inserting all the boilerplate code necessary for running the application across multiple tiers and making asynchronous invocations. Finally, you deploy the modified assembly on any target execution environment that is capable of executing MSIL.

Because Volta works on the MSIL level, it is completely language and target execution environment agnostic. In particular this implies that further translation of MSIL to JavaScript is a completely orthogonal decision with respect to declarative tier-splitting and asynchronous method definitions. You can use Volta to create distributed applications where the client runs on say the regular desktop CLR as easily as ones that run inside the browser.

Another benefit of working on the MSIL level is that the Volta tools have a holistic view of the complete application. For instance, this enables end-to-end profiling by injecting instrumentation hooks into the MSIL as part of the tier-splitting rewriting process, but also seamless cross-tier debugging. Again, these benefits are agnostic of both the source language (such as VB, C#, F#, Eiffel, …) and the target execution environment.

The GWT takes source code written in Java only and directly compiles it into JavaScript.

As a result, you can not directly use the GWT to write AJAX applications in other languages that target the JVM such as JRuby, and it does not directly support writing distributed applications with a regular rich Java client.

Declarative

Volta tries to minimize the number of steps it takes for developers to refactor a client-only application into a multi-tier application. To make instances of a class run on the server in Volta , you express your intent declaratively by placing the custom attribute [RunAtOrigin] on the class declaration.

To create an asynchronous version of a method, you similarly declaratively mark an extern signature declaration using the [Async] custom attribute. There is no special interface that the MyService class needs to implement.

In the GWT achieving the same goal requires the programmer to define two interfaces and one class and extend/implement two required base types RemoteService and RemoteServiceServlet.

Independently extensible

The GWT uses Java native methods to interface to JavaScript where the JavaScript implementation of that native method is defined in a special pragma comment.

In many situations, the compiler can automatically infer the JavaScript implementation from the metadata for the corresponding function declaration in C# (or VB). The Volta toolkit therefore implements a sophisticated convention over configuration heuristic to simplify writing foreign function interfaces. As a result this typically enables programmers to import JavaScript functionality by just writing a single [Import] attribute on an extern method signature.

When occasionally the programmer needs to explicitly provide the JavaScript for a given method, the JavaScript code is passed as an argument to the Import attribute and checked by the Volta post-compiler for syntactic correctness.