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...
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.
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.
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).
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).