Was JavaScript a mistake?

Standardizing on a single language puts too many eggs in the browser's basket.

Ever since the early days of Web browsers we've had this language, JavaScript. Over the years, we've demanded more and more of it, to the point that we're now talking about using it to build entire applications. The simple truth, however, is that JavaScript will never be good for everything.

Rather than shoehorning more and more functionality into the browser itself (and going through all the rigorous standardization procedures that this requires), maybe it's time we separated the UI from the underlying client-side logic. Let the browser handle the View. Let the Controller exist somewhere else, independent of the presentation layer.

We already have a means to achieve this separation for client-side code today: browser plug-ins. Of course, most Web developers will tell you that plug-ins are a Bad Thing. Every time you force the user to download and install a plug-in, says the popular wisdom, you throw a roadblock in front of your code. But is that really true?

Early browser plug-ins were mostly designed to deliver multimedia. Typically it didn't take long for them to become vehicles for online marketing -- and this at a time when most computer users connected to the Internet via dial-up. Little wonder that no one could be bothered to download them.

The modern counterexample is Google Gears. Install the Gears plug-in once, and every Gears-enabled application gains additional functionality. To date, the list of enabled sites includes not only Google Docs and Google Reader, but MySpace, Picasa, and even WordPress blogs.

People tend to focus on Gears' ability to allow Web applications to be used while offline. They overlook the WorkerPool module, which allows JavaScript code to run in the background, independent of the code on the main page. WorkerPool is a standalone code execution engine; it just happens to run the same JavaScript as an ordinary browser.

So why JavaScript? Why not Python, or Lisp, or some other, new language designed with an alternative Web application development methodology in mind? If the application that it powers is compelling enough, the incentive to install a plug-in is high -- particularly in this age of readily-available broadband.

An external browser module capable of executing most of the proposed ECMAScript 4 specification already exists: It's the Adobe Flash plug-in. Other platforms are available as plug-ins, as well, including Curl and REBOL.

As Web developers, we tend to shy away from these alternatives, but only because of the never-ending efforts to refine and standardize JavaScript within the browser itself. Because it's a Web standard, we tell ourselves, JavaScript is the "purer" option.

But if sticking to a single way of doing things is what we want, then why reinvent the wheel? We already have an all-purpose client that's capable of acting as a front end to a wide variety of applications, from databases to e-mail. It's installed at thousands of enterprises worldwide, right now. It's called Lotus Notes.

Is that the way we're heading? Is that really the model for the browser of tomorrow? Or is it time for the Web development community to start thinking outside the box?