What did Javascript have that Java did not?

Share the article!

Brendan Eich, creator of the Javascript language, summarizes its future features in this piece. It includes an interesting paragraph about a JIT (Just in time compilation) Javascript Virtual Machine:

For Mozilla 2, we will have a JIT-oriented JavaScript VM (details soon) that supports the forthcoming ECMAScript Edition 4 (“JS2″) language. Among the desirable characteristics of this VM will be a conservative, incremental garbage collector (GC)…This will kick Ajax performance in Firefox up a notch or three.

Now just in, we read from CNET that Adobe has donated its Javascript engine (codename Tamarin) to firefox. This is the latest version of Actionscript engine that is released with Flash Player 9. It uses a just-in-time compiler that is said to “run programs ten times faster than previous versions”.

When one reads news like this, one begins to wonder, “what does Javascript have that Java does not offer?” Afterall, a JIT compiler has existed for Java for I think over a decade (i.e. for the historically inclinded October 25, 1996). Surely there must be features of Javascript that the Java design has overlooked. I was reading Thomas Landspurg’s entry on “Gmail for Mobile” and he makes a striking observation:

MIDP still have some works to do, especially on the ability to launch one app from an other. Today, no way to launch GMail client from Opera Mini, or from a Widget engine. You need to exit, and find the app by yourself.

Now granted that this is a feature of the distributed hypermedia web and not Javascript per se. Javascript like a virus has intertwined itself with the recombinant DNA of the web. That’s because in a ecosystem of decentralized loosely coupled entities program logic is most effectively done at the edges. That is, it is “integration at the glass” a late-binding approach to integration. Albeit it feels like a toy, Javascript satisfies the 80/20 point.

That still doesn’t answer the question though, after all, the meteoric rise of Java was on the virtue of its ability to run applets on the browser (that’s before people realized its benefits on the server). However, unlike Javascript, Java applets always seemed like an appendage. That was compounded with its excruciating long startup times. The Javascript and HTML interpreters are tightly intertwined in execution (i.e. the HTML parse tree, a.k.a. DOM is available to javascript), Java bytecode appears more like an outsourced operation.

The problem appears to be that the surface area for interaction with the HTML page was too small. In hindsight, the task to develop richer and more convenient interactions with the underlying HTML page structure was never undertaken with any real seriousness.

However, the very nature of Java, a statically typed language may have more to do with its failure as a web language than any other techical issue. The industry has this bad habit of framing solutions based on old paradigms that are incompatible with the new. We saw it in the SOAP debacle, where everyone was trying to force fit the web into a distributed object programming model. Sometimes, one has to resign one’s self with to revelation that it just doesn’t fit.

Languages based on static inheritance and typing are good for building complex silo (i.e. closed world) based applications. However, a global scale Architecture of Participation requires more dynamic structures like that found in prototype based inheritance and dynamic typing. In such a massively open world, the distinction between metadata, configuration and instances is simply impossible to pin down into well defined classes and configuration files.

When Google unveiled GWT they wrote:

Writing dynamic web applications today is a tedious and error-prone process; you spend 90% of your time working around subtle incompatibilities between web browsers and platforms, and JavaScript’s lack of modularity makes sharing, testing, and reusing AJAX components difficult and fragile.

Yes, without a doubt Javascript lacks modularity and definitely messy. However folksonomies like del.icio.us that lack a well defined taxonomy are messy. Value is more situated and is in the eye of the beholder, just as a good script is a script that just works. In the domain of situated and remixable software “cut and paste” collaborative reusability may just happen to be good enough.

Javascript by its design is fundamentally messy, however that is its advantage over Java. The path to any sanity may just be what Google has shown, when building silo apps, hide the messy details under a clean well defined Java facade. Never forget though, that these facades are abstractions that leak. Always afford your applications the ability to escape into the Web and Javascript when necessary.

Reminder to self: Discuss Excel


Share the article!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>