The RIA and the Polyglot VM

By chromatic
December 3, 2008 | Comments: 3

In Artificial Complexity and Internet Applications I bemoaned the Frankenstein's monster which modern web applications represent. A database-driven application uses SQL and some DDL to model entities and their relationships, a general purpose programming language for business logic, often a templating language for client-side display, HTML and CSS for presentation, and often JavaScript for client-side UI -- not to mention any little languages for configuration and deployment of various pieces.

In The Magic of Web Apps is HTTP, Not the Browser I argued that the browser is the worst of all possible interfaces with its paucity of widgets -- checkboxes, radio buttons, text boxes, and submit buttons. The success of web applications is not that the browser is a good platform. It's that ubiquitous access is sufficient orders of magnitude better than the alternative that we'll put up with degradation of user experience.

In return for hobbling your application and building a teetering tower of complexity, you get a fragile application with many moving parts which hopefully works on various browsers running on various platforms, unless you run into underspecified incompatibilities regarding presentation or behavior. I mention JavaScript stagnation only in passing, as that's the focus of tomorrow's post.

Weren't web applications intended to save us from this mess?

A better solution solves both problems: the ability to write your application in one language (or multiple dialects, as appropriate) on client and server side. (The best solution will ultimately be exposing a RESTful API and allowing many clients, but you'll see why this isn't an option shortly.)

At least, that's the idea behind Silverlight, JavaFX, and Adobe AIR. While the hook may be "HTML and Ajax and CSS can't produce good UIs", however much that's true, the real goal is a unified platform for the complete application, just like the good old days.

Of course, the obvious problem with this approach is that a big blob of proprietary goo is only a solution for people who want to (or have permission to) get that goo all over their machines. Remember how boggled your bank was back in 2004/2005 that you weren't using Microsoft IE (or that no version of IE had ever run on your OS)? Imagine explaining to them that your 64-bit PC-BSD machine will never get a native version of AIR, and you'd really like to write a check.

At least with bog-standard HTML and CSS (and sometimes, Ajax), the horrifyingly ugly interface works.

The technical design is right, however. A powerful virtual machine, capable of hosting interoperable languages and expressing useful and distinct dialects could improve the state of network-savvy, ubiquitious applications. Don't expect it to come from a proprietary blob, however -- and don't expect JavaScript to be the answer. Microsoft made sure of that earlier this year. I'll explain how tomorrow.


You might also be interested in:

3 Comments

At least, that's the idea behind Silverlight, JavaFX, and Adobe AIR. While the hook may be "HTML and Ajax and CSS can't produce good UIs", however much that's true, the real goal is a unified platform for the complete application, just like the good old days.

At least with bog-standard HTML and CSS (and sometimes, Ajax), the horrifyingly ugly interface works.

There's some truth in these statements, but the Web Accessibility Initiative's Accessible Rich Internet Applications Suite and the WebApps Working Group's standards put forward by the W3C will help change that. (See also this Firefox 1.5 Accessible Widgets from Juicy Studio.)

In return for hobbling your application and building a teetering tower of complexity, you get a fragile application with many moving parts which hopefully works on various browsers running on various platforms, unless you run into underspecified incompatibilities regarding presentation or behavior. I mention JavaScript stagnation only in passing, as that's the focus of tomorrow's post.

When you last used JavaScript were you using the crappy old broken IE and Netscape models or were you using the DOM specified models? Have you tried using jQuery, MooFx, Prototype, Scriptalicious, or another JavaScript library? They make things a lot easier and handle most of the "teetering complexity" problems you decry here.

A database-driven application uses SQL and some DDL to model entities and their relationships, a general purpose programming language for business logic, often a templating language for client-side display, HTML and CSS for presentation, and often JavaScript for client-side UI -- not to mention any little languages for configuration and deployment of various pieces.

I've read this a few times, and I'm not sure I understand why this is a problem. If you're building a house, you want skilled people putting in each system (plumbers for water/sewage, electricians for power, carpenters and bricklayers for construction) rather than one guy who "sorta knows" what he's doing on all the systems.

A better solution solves both problems: the ability to write your application in one language (or multiple dialects, as appropriate) on client and server side.

I'm sorry, I just don't see this as a problem. Developers and computer scientists have been looking for the "one language to rule them all" forever, and come up empty. And aren't your "multiple dialects" just a single step away from "multiple languages?" Consider the variations of SQL, C, C++, and English (American vs. British).

I'm with mbear: the last time I went near Flash or AIR, I was shocked at how much harder it was than modern JavaScript - and how much worse the results looked and behaved (the mouse scroll wheel is a custom behaviour in 2008?). Silverlight is a complete non-starter (proprietary, mixed-to-worse language, none of your clients have it, etc.) and, well, Java applets aren't exactly noted for rich UIs.

The modern JS libraries are quite good and avoid most of the browser pain - in exchange, you avoid the nightmare which is supporting a VM runtime and having to develop alternatives for all of the functionality which you get in a modern web app (e.g. iPhone support, Google, accessibility, etc.). It's also a LOT harder to find good developers and you're stuck sharecropping in a proprietary vendor's world.

The other trend is that you can do what you want with fewer languages by embracing the web-native environment: there are now a number of JavaScript-based programming environments and between web services and full REST databases (CouchDB, FeatherDB, etc.) you can actually cut the traditional server-side coding out of the mix (not to mention that an XML/JSON store ends up being more natural fit for modeling many business processes).

Here's another alternative - an open source platform built on top of technologies like Gears, Webkit, and Chromium that allows developers to build rich applications that run natively on the desktop using HTML, CSS, and Javascript, as well as Flash and Silverlight. We launched a preview release of Titanium today - thought you'd be interested. http://titaniumapp.com
Using Titanium with Appcelerator also allows for easy integration with leading server side languages.

David at Appcelerator

News Topics

Recommended for You

Got a Question?