Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

Tamarin

On Tuesday, the Mozilla Foundation and Adobe announced the Tamarin project, an open-source ECMAScript virtual machine based on the ActionScript engine used by Flash Player 9.

Frank Hecker’s overview of what this means is useful, but the Tamarin source code itself provides this interesting piece of historical insight:

AVM+ is the ActionScript Virtual Machine

AVM+ offers an order of magnitude performance increase over the “Classic AVM” in Flash Player 7. Our performance target is 10X.

AVM+ implements ActionScript 3.0, the new version of the ActionScript language that is compliant with the ECMAScript Edition 4 standard.

AVM+ is also built for modularity. It will be part of the Flash Player, but is a self-contained module which can be incorporated into other programs with ease. It may also be submitted to the ECMA standards organization as a reference implementation of ECMAScript Edition 4.

Adobe’s reputation for solid engineering shines through here—it seems that what is now Tamarin was designed for integration with other applications from the very start.

The most important thing we can expect from this is a serious improvement in JavaScript performance in the Mozilla family of products, thanks to Tamarin’s JIT compiler that can convert ECMAScript bytecode to machine code at runtime. JavaScript/Ajax applications will run faster, and the Mozilla applications themselves will perform better as much of their UI is written in JavaScript and XUL.

This performance boost will benefit other applications as well. Tamarin is being integrated with SpiderMonkey, which is used in a variety of applications such as the Yahoo! Widget Engine.

Reading through Brendan Eich’s technical overview of Mozilla 2, it looks like the Mozilla team also plan on taking advantage of this performance boost to move code from C++ to JavaScript 2 in many places, simplifying their code base and reducing the likelihood of security flaws in the code.

Even in these buzzword filled days of Ajax and Web 2.0, JavaScript is still seen as a poor cousin to so-called “real” programming languages. With a high performance open-source VM like Tamarin available, maybe more developers will start to re-examine JavaScript’s role outside the browser.

Posted 9th November 2006 at 12:24 pm

This is Tamarin by Simon Willison, posted on 9th November 2006.

Tagged , , , ,

View blog reactions

Next: WriteRoom

Previous: Fun with ctypes

12 comments

  1. About your last words: I happened to find myself on the Adobe Apollo - http://labs.adobe.com/wiki/index.php/Apollo - web page and I was wondering the same stuff. If Apollo takes off on the desktop it will be a huge spread out of Javascript as a multi purpose language. What do you think?

    Lawrence Oluyede - 9th November 2006 13:41 - #

  2. One thing that would help acceptance of "JavaScript's role outside the browser" is a well-known, universally available implementation of a standalone JavaScript interpreter. Microsoft have JScript, but the Windows-only nature of it makes it relatively niche (many of the target Windows scripting audience will prefer VBScript).

    Paul Moore - 9th November 2006 16:29 - #

  3. yet another vm? it would be interesting to see how this compares to retargettable vms like parrot, or other jit packages for dynamic languages like luaJIT. i am not sure the claims of 10x spidermonkey performance are that interesting, its performance characteristics are so poor that most present day dynamic environments are already 10x spidermonkey performance

    grumpY! - 9th November 2006 17:27 - #

  4. And imagine having a server side javascript engine. This would open a very nice development model : same langage used on both side, sharing the same code base with different security concerns. Maybe this already exists, but having a fast javascript vm will make it more practical. And maybe, just maybe, this could be included in php, like they did with sqlite for embedded databases...

    Philippe Jadin - 9th November 2006 19:42 - #

  5. I've come to realise the power of JavaScript in the last few months and been pushing it hard in my company. If people are investing time and money in developing applications in JavaScript, you'd want to be able to move it out of the browser, onto the desktop and the server.

    Thom Shannon - 9th November 2006 21:05 - #

  6. Why would you integrate Tamarin into Spidermonkey? Doesn't Tamarin replace Spidermonkey?

    Ian Bicking - 9th November 2006 22:01 - #

  7. Philippe: server side JS is an old idea that Netscape actually put into practice back when they were making some of the best HTTP server implementations out there. I believe those old codebases now belong to Sun, so it would be interesting to see if they still support JS on the backend.

    Thomas Lockney - 9th November 2006 22:42 - #

  8. Thom, would you also implement the entire browser host environment? Before you do that, take a look at Dojo, which provides a pretty nice shim for different runtime hosts.

    Jeremy Dunck - 10th November 2006 04:50 - #

  9. server side ecmascript? why??? do you plan on implementing all of the basic out-of-the-sandbox system access that perl had in 1995, and then spend two years debugging it? and once you do, is it even ecmascript anymore or simply your own private frankenstein language?? whats needed is language independence in the client, not javascript handcuffs on the server.

    whoops - 10th November 2006 05:36 - #

  10. Um, server side Javascript? Since IIS 1, which is what, ten years ago?

    I never understood why anybody would want to use a different language on the client and the server.

    Kirit - 10th November 2006 13:10 - #

  11. Kirit - because fifty man-years of debugged libraries is more important than syntax?

    whoops - 10th November 2006 17:08 - #

  12. whoops-- I'm pretty sure Kirit was referring to the typical development pattern done on top of IIS, which was ASP on the server (in the form of VBScript, a truly awful language) and JS on the client.

    Pitting Perl (or any language with reasonable design and libraries) is a total strawman. Kirit's question is reasonable. If choosing between JS on both server and client or JS on client and VBScript on the server, it seems a straight-forward answer, yet most IT shops have gotten it wrong for years.

    Jeremy Dunck - 11th November 2006 04:16 - #

Comments are closed.

Previously hosted at http://simon.incutio.com/archive/2006/11/09/tamarin

A django site