Mozilla Paints the Future of Web Scripting with Monkeys

Posted by James Estes on Aug 14, 2007 12:10 AM

Community

Java

Topics

Javascript

Tags

IronPython,

IronRuby

There has been a lot of Monkey talk going on in the Mozilla circles recently and if you're a web developer (or you like Monkeys) you'll be interested in what they have to say. The talk centers around 5 different projects at Mozilla, all of them quite powerful and telling about the future of browser scripting. Here is a summary for those not already familiar with the projects:

SpiderMonkey is the code name for Mozilla's JavaScript engine. That's nothing new, as it was the first Javascript engine and was used in the Netscape browser.

Tamarin is the ActionScript engine that Adobe donated to Mozilla back in November. Tamarin has a just in time compiler that compiles Javascript down to machine code and boasts a better garbage collector. It also supports ECMAScript 3 and is working toward full ECMAScript 4 (JS2) specification support.

ActionMonkey is the code name for the project underway to integrate the SpiderMonkey and Tamarin engines. The product of this merge will be the engine for the Mozilla 2 platform. This would bring the performance improvements AND the latest specification support of Tamarin to Firefox and other Mozilla based apps.

ScreamingMonkey is an effort to get the Tamarin Engine running in non-Mozilla browsers. This brings the same Tamarin benefits to the other browsers (starting with Internet Explorer). So those other browsers are brought, "kicking and screaming" into a world with a homogenous, fast, standards compliant scripting engine implementation.

IronMonkey wants to map Microsoft's Common Intermediate Language (CIL) to ActionScript Byte Code (ABC). This would allow code written in IronPython and IronRuby to be run on Tamarin. Which, when paired with ActionMonkey and ScreamingMonkey, means running Ruby/Python code in the browser.

All this monkey business really does add up to a pretty exciting road ahead for browser scripting. We're looking forward to improved performance, ECMAScript 4, fewer browser quirks (at least as far as the scripting engine), and support for different scripting languages. While it is exciting, not everyone agrees that this shift is the right one, at least not the decision on the virtual machine that will get us there. Some of the feedback has been that perhaps the Java Virtual Machine or Mono would have been better choices. Java already supports JRuby and Jython, covering the 'different languages' front and the hotspot engine running Rhino has good performance. Mono would allow for both of these features as well. John Resig summarizes the reasoning behind the Tamarin choice:

...in a nutshell: The non-technical reasons for choosing Tamarin are over intellectual property and licensing issues and the technical issues are related to compilation speed, file size, and memory footprint.

• Older >