Summary
A great deal of commentary followed Apple's announcement that it would use the Sproutcore JavaScript framework for its upcoming online offerings. Most of the debate centers around the question of whether a virtual machine-based environment or reliance on browser standards are preferable when developing rich Web apps.

Advertisement

Many server-side applications are now written to target a virtual machine, be that the Java VM or Microsoft's .NET environment. Virtual machines not only alleviate many hardware differences from an application's point of view, but also add benefits not available to applications that explicitly target the native host.

One example is just-in-time compilation: A JIT compiler has access to runtime information that a static compiler doesn't, and can, potentially, use that data to affect application performance. Another benefit of VMs can be seen in the rise of polyglot programming, as most modern VMs facilitate some interaction between code written in different source languages. But the biggest benefit of targeting a virtual machine is that it provides a homogeneous environment that can be be expected to work similarly in otherwise disparate hardware and OS environments.

Could a virtual machine-based approach provide similar benefits on the client as well? In many ways, the state of client-side development is akin to a situation that existed for server-side applications prior to the rise of the major VMs: Although there are standards that many environment vendors claim to follow, browsers are far from homogeneous.

As with server-side development some ten years ago, developers have taken two primary approaches to making things easier on the client: using libraries that mask some of the environment differences, such as Prototype, script.aculo.us, or Dojo, or using clever compilers that can emit highly optimized code for various targets, such as Google GWT.

While those two approaches consume a fair amount of developer mind share, Microsoft, Sun, and Adobe seem to think that the future of client-side development bliss lies in virtual machines. With Silverlight, Microsoft aims to provide a multilanguage development paradigm for client-side applications, similar to what it has done on the server, and Sun's renewed interest in applets and the client offers the JVM as the target environment for rich-client applications. Meanwhile, Adobe's Flex, which targets the Flash VM, has reached its third iteration, has been available for a while under an open-source license, and now with BlazeDS has a compelling server-side integration story as well.

When Apple announced last month that it would be using Sproutcore, a nascent open-source Ajax framework, for its upcoming online offerings, some speculated that with this move Apple aims to throw its weight, and considerable number of followers, behind the cross-browser library-based approach to rich clients. RoughlyDrafted's Daniel Eran Dilger went so far as to consider, in Cocoa for Windows + Flash Killer = SproutCore, much broader possible implications of Apple's move:

Apple is refining Cocoa for deployment within the web browser to enable developers to build those so called “Rich Internet Applications” that Adobe wants users to build in Flash/Flex/AIR, Microsoft in Silverlight, Sun in Java, and so on...

Many of the most popular rich web apps today are from Google, including Maps, Reader, Docs, and Sheets. Google’s rich web apps take on Microsoft Office desktop apps without even needing Flash, Silverlight, or Java. Instead, Google simply uses open web standards: HTML, JavaScript, and CSS. If Google’s leading rich web apps avoid using those proprietary plugins, why should anyone else resort to using Flash or something similar?

Google’s frequent partner Apple has been thinking along the same lines, scrubbing its website of all unnecessary Flash elements and building everything in those same open web standards: HTML, JavaScript, and CSS.

Indirect strategies explain why both Google and Apple share the same strong affinity for an open web, in contrast to more short sighted developers would would blindly shackle themselves to Flash or Silverlight simply because those tools might help them accomplish their immediate objectives without too much effort.

For server-side applications, many developers have been more than willing to "shackle themselves" to VMs, precisely because VMs have helped them to "accomplish their immediate objectives without too much effort," i.e., to develop and deploy applications consistently across multiple platforms. And on the client, too, developers using Flex, for instance, have been experiencing similar benefits.

Although cross-browser Ajax libraries are getting better all the time, Tim Anderson pointed out that even Sproutcore, in its current stages, has a rough time supporting the major browsers:

I tried the sample controls demo in IE7 but it didn’t work quite right. For example, the Picker pane opened but would not close. Tried again in Firefox 3.0 and everything was fine... I’ve got no idea what the problem is with IE7; it is probably because of weak standards support in IE. However, it illustrates the advantages of a plug-in like Flash, Silverlight or Java. With these platforms, the application is largely insulated from differences between browsers.

Even beyond the cross-browser capability, VMs offer advantages that the Ajax/browser-based approach can't. According to Adobe's John Dowdell, who may be biased given his company's commitment to Flash and Flex, writes that:

Frameworks promise developmental ease, and hope to reduce testing time. But they don't add capabilities to the audience's machines. Runtimes do that. Targeting the intersection of various runtimes (as with HTML/JS/CSS) costs more than targeting a single universal runtime (Flash), whether in testing, support, or (critically) range of supported functionality...

In other words, VM runtimes, such as the JVM, .NET, and Flash, can add benefits to rich-client applications in similar ways that VMs on the server add benefits to server-side applications.

Targeting a VM-based client environment also renders browser vendors' adherence to standards less important for developers. That may be a good thing with the upcoming release of JavaScript 2: Although Mozilla has committed to supporting the much improved version of JavaScript, Brendan Eich, JavaScript's creator and CTO of Mozilla, did not express great hopes for Internet Explorer supporting JavaScript 2 any time soon. This is not only a question of libraries or browser idiosyncrasies: Without wide support for JavaScript 2, developers would either be forced to write in earlier JavaScript versions, never really taking advantage of features in JavaScript 2, write two versions of JavaScript applications, or rely on a compiler that can "downgrade" JavaScript 2 code for browsers not yet supporting that language.

Interestingly, Eich noted in a recent interview that developers may be able to use JavaScript 2 in IE through a plug-in, ScreamingMonkey, that Mozilla and Adobe jointly co-sponsored. ScreamingMonkey does this by relying on the Flash player, whose compiler, Tamarin, already supports the latest JavaScript draft standard:

It’s possible that if you’re a developer and you get this [ScreamingMonkey plugin], or if Adobe were to distribute this active scripting glue that Mark [Hammond] wrote, that IE would be able to support JavaScript through the Flash Player. It wouldn’t need to have native support for JavaScript 2, it would get it just for free because Flash is widely distributed. Now I don’t know if Adobe will do that. It’d be good if they did, in case Microsoft does not ever get around to supporting JavaScript 2.

Personally, I'm not sure one has to make an absolute decision about the VM-based approach vs the browser/standards-based approach to rich-client development. For individual projects, however, one does have to make a choice about technology. My personal experience is that using a VM on the client offers benefits that one just can't get even with the best Ajax libraries, such as YUI or Dojo. For example the Flash VM provides highly sophisticated debugging and profiling support, and can offer JIT compilation for running Flex applications.

Where do you stand in the debate about VM-based vs. browser standards-based approaches to rich-client development?

It's not about VM versus standards support.It's about Single vendor platform versus competing browsers.Google had to support Mozilla so that Microsoft would improve Internet Explorer. Apple was forced to build Safari instead of putting up with an outdated browsing experience.

What if Adobe/Microsoft/Apple feel they don't have to innovate their platform? (Or Apple buys Adobe and replaces flash by quicktime). Then your app has just about as much future as ActiveX controls or java applets

In my opinion web standards are about much more than cross browser or cross platform compatibility. There are many other important characteristic of a page that are a function of how well the page supports standards.

For instance, to make a page accessible a definite first step is to make it standards compliant, or as I normally say, make it AT LEAST standards compliant!

Additionally, if a page follows standards it is typically more indexable by the normal search engines, it renders and downloads faster (specially if you separate content from style) and it is certainly more maintainable than a non standard page.

I think than when you evaluate a framework or a runtime on the client side, you have to remember that a page has this characteristics that are as important as how the page looks on different browsers.

I am not sure about the framework that Apple is nos pushing, but in the past runtime frameworks have had a lot of issues when looking at accessibility, SEO, etc.; Also, the fact that the framework might not reside on the client machine might also be an important deterrent for users.

Now, why is that developing with standards in mind resisted that much by the community? Browser support of standards is certainly one answer and all the major browser vendors are working on it, but what else? I also believe that the fact that browsers are not more strict with respect to the syntax they support is an even bigger problem. With the excuse that we wanted to make "accessible" to any "developer" the ability to write web pages, all browsers now support a completely non defined "language" (it is not "pure" anything) and therefore the chances of making mistakes is enormous.

Summarizing, it is important to evaluate runtimes beyond their ability to generate cross browser compliant code. You also need to evaluate them on how accessible, findable, etc the code they interpret is.As a last comment, I believe it would be much better for the industry to push towards standards compliance and the ability for all clients (including bots...) to accept the same language even if the language is less expressive. Once we'll have a common ground we can grow from there.

The only plug-in we need is an easy to install ActiveX wrapping the FireFox web engine on top of Internet Explorer. This way we could to use FireFox rendering engine on Internet Explorer much like we use Flash. There is one but is not ready for prime time and needs FireFox installed before.

SVG, canvas, persistence on the client, faster JavaScript, good mobile browsers... the future of web is exciting and promising. The only problem is Internet Explorer.

First off, nice article, I am glad to see the spotlight shining a bit on this topic - no matter which may most opinions fall.

In my opinion, which definitely is Ajax biased ;), I think there are many advantages to relying on the native VM built into the browser platforms, rather than relying on another third party VM.

The argument that John Dowdell makes is actually a bit of a downside in my mind - rather than a plus: "Frameworks promise developmental ease, and hope to reduce testing time. But they don't add capabilities to the audience's machines. Runtimes do that."

Frameworks don't add different controls and or complete metaphors that users may not be familiar with. Every runtime based RIA app may have different UI controls, and different ways to deal with concepts like "bookmarks" or the "back" button - frameworks work within the web stuff - which is good, users understand it, and like it.

Along those same lines though, frameworks often don't have as "rich" a set of controls or even operations. But personally, I don't find that to be a bad thing when considering all you can do with "native" (to the browser) code.

As the article notes, the Apple web site is pretty slick, check out how the store items automatically page themselves including the images as you scroll, all with relative slider bars. Or look at the Flickr organizr, etc - pretty impressive stuff, arguably stuff that covers 98% of what people need to do, for web based apps, can be done without a specialized additional VM.

And, as to "Targeting the intersection of various runtimes" costing more than a single runtime, sorry, but that doesn't make much sense. There are costs for both approaches, true, but there is no "single runtime." Just like somebody has to put a lot of effort into building a framework to get it right for cross-browser usage, so must a runtime developer put in that effort for the runtime itself.

The difference is with the framework approach it works the day it's ready for browser X, it doesn't have to wait for runtime Y to be ported to platform Z.

I can use many Ajax apps right now on my Wii and my iPhone, for instance, I can't use any Flash/Flex/Silverlight based apps on either of those (yet, but that yet is a big yet, that's my point).

In total though, I think the best approach right now is to use BOTH native HTML/JavaScript/CSS for the UI and underlying runtimes - if present while falling back gracefully - for computation and operations. For example, back to Flickr, have you used the Flickr uploadr? No, I don't work for Flickr, but this is the best file handling dialog I have seen *anywhere*, period - RIA, web, desktop, you name it. It uses Ajaxy HTML/JavaScript/CSS for the UI, and relies on the some Flash runtime components to do the processing and feedback (I think). If Flash isn't there, it still works, it's just not as "flashy" (sorry, couldn't resist). If the power and functionality of the runtime is there, use it, but don't use it for UI (stay native with that).

Interesting essay, though I take a stronger view on Rich Internet Applications (RIAs) vs what I call Native Web Applications (NWAs) - that is, one should only ever use an RIA if they absolutely have to to access some feature (eg video capture, and indeed video playback for the time being), or if they absolutely need local computing (eg for online gaming). Otherwise the cost in terms of penetration for your application is just too great (and ever increasing).