A Monkey Made of Clay
Adobe is making some real noise on the platform front. I have written about the Apollo project, and now we have the announcement that Adobe will be providing key elements of Mozilla’s JavaScript runtime as part of the Tamarin project. Specifically, Adobe has a JIT compiler that will take ECMAScript bytecode and emit native instructions, supposedly yielding up to a 10x speedup. Also in the offing is a new garbage collector, whose impact isn’t really clear yet. I am probably most interested in the interplay between the GC and DOM because there seems to be a lot of dirt hiding in that crevice.
Tamarin will find itself used in a variety of Adobe products, including, eventually (probably) Apollo, as well as Acrobat and Flash itself. For its part, Mozilla’s implementation of ECMAScript v4 will be Tamarin, so we will likely all be seeing the fruits of this cooperation as development progresses.
There are a lot of positives here: Mozilla is arguably the gravitational center of JavaScript development (meaningful nod to Opera, too), and Adobe is providing some great technology that has already been proven in the field by virtue of the role it plays in Flash 9. The combination of the two will yield great things.
And now the part where I express my reservations: The tension between JavaScript’s privileged place in today’s software industry and its future as a programming language is at risk of coming to a messy boil. JavaScript is a very interesting language, there are upsides, and there are downsides. All in all, I am fine with it. Yet it would be nowhere if it were not the required language for doing client-side web development. The browser has become a significant platform, and JavaScript in the browser + PHP on the server has become a very potent combination. In fact, it is arguably the easiest way to write simple client-server data retrieval applications.
So now we have a language that has legitimate prospects of its own, that owes its success to the browser, and is a key component of the browser. This is where the tension enters. During today’s IRC chat with Brendan Eich, the question of why Mozilla rejected Mono as their VM elicited the response that Mono is too big, and not focused on browsers. Makes sense if you’re worried about Firefox, but is this really what you want to hear if you’re thinking about the browser as your application platform? The same question can then be asked of ECMAScript 4.
There are a lot of VMs out there, and the debates about whether various projects should use one or another typically rage back and forth with convincing points made on each side, but the debate about the VM for ECMAScript 4 has a built-in ending: Adobe’s technology is tailored for the browser. Good point. Eich says that Mozilla as a platform is strengthened by its focus on enabling Firefox the application (among others). This is a sensible approach for developing and testing functionality, but not for determining the extents of your technology’s reach. I fear that decisions made to make Firefox the best browser may cause the platform to languish, and the language with it.
The giant opportunity for everyone else: Provide an environment that makes client-server “AJAXy” applications dead-simple to write, while not worrying about shipping a lightweight web browser.
