Showing posts with label gwt. Show all posts
Showing posts with label gwt. Show all posts

Monday, February 04, 2008

Quick Poke: Look at MS Live Labs' Volta

If you haven't seen Microsoft's Volta project, it's worth a look.

Volta is about two big things:

(1) Blurring the lines between applications tiers to allow declarative or even automated tier-splitting (yes, there are lots of issues with this, but the MS team insists it's aware of the historical legacy of the distributed computing "leaky abstraction" and won't muck things up by pretending it's not an issue).

(2) Automagic cross-compilation between, say, .Net IL and JavaScript.

Whoa, what's that last bit?!

After the initial flurry of press coverage, the team insists that running arbitrary .Net IL on any old JavaScript-capable browser is no big deal, just a convenient demo, don't focus on that part... But, seriously folks, a couple of months on since the project was made available to the general public, the tier splitting is looking less and less interesting, and the cross-compilation is looking more and more interesting.

Once upon a time, crazy people did crazy JavaScript stunts. Like this demo that emulates the hardware of an entire 80s-era game system complete with game, or this similar 6502-based emulator.

Emulating a modern VM like the JVM or CLR is not practical from a performance point of view. But JavaScript runtime as a compilation target is becoming increasingly popular: first we had GWT and Script#, which compiled Java and C# respectively to JS. But because they only compiled your code supplied minimal bits of the respective class libraries (Java API/.Net BCL), their use was restricted.

So here's a wicked end run around that: take anything that compiles to IL -- or any IL binary! -- and run it in a browser. According to the Volta team, it has been done in such a way that all of the object semantics from the original language are preserved. Unless they also port the Win32 API to JavaScript, it's not like we're going to see WinForms apps running on Safari. But this is being positioned as a fallback for, say, places where Silverlight isn't installed.

Go here and look at the demos. The perf is awful -- but that's not the point of the demos. So far as I can tell, this is the first commercial implementation of what we all kind of knew might be coming.

Friday, May 04, 2007

Interaction Sequence Diagram for Google Web Toolkit

I've been doing some work with Google Web Toolkit. GWT is based on a cool model where the client-side and server-side code are both written in Java. The client-side code follows certain API guidelines which allow it to be compiled to optimized Javascript by GWT. Among the APIs that can be used is a pattern for asynchronous remoting, so that AJAX calls can be made and received in Java, with Java objects as arguments and return values (a bit like RMI). The marshaling and unmarshling, JSONizing and the like is done automagically. Nikhil Kothari has a similar technology on the .net side that lets you code client-side Javascript via C#. It is called Script#.

This model has a number of major strengths. But one weakness is that is not common, so it is not immediately familiar to developers. The interaction pattern can seem a little mysterious even with Google's doc set, debugging tools, etc. It gets more interesting when you consider that you might also be generating the original pages (the ones with AJAX interactions on them) via Java. (GWT does not require a dynamic page generation scheme at all, and can use static HTML.) In order to make this clearer, I wrote a sequence diagram which I'm posting because it may be valuable to other developers getting their heads around GWT.

The diagram shows three interactions. First, I'm generating my initial pages using the FreeMarker templating system. There are lots of other ways (like JSP for example). But here I'm using FreeMarker. This all takes place before GWT gets involved in the pages.

Next, I show how the GWT scripting gets running and loads the page specific code which will rewrite the DOM. At the end of this, the page is rendered the way the user will see it in the browser.

Last, I show how an AJAX interaction flows, including a call to an external web service on the back end -- e.g., if there is a "Load My Favorites" button on the page that results in a call to an external service and asynchronously returns with data to bind into the DOM.

I hope it's helpful. If I've left anything key out, let me know.

Click to enlarge / view: