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.

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?

Talk Back!

Have an opinion? Readers have already posted 6 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.