Ajax Girl

John Resig has aggregated the Why Tamarin? debate:

What’s the advantage of Tamarin over integrating the Mono VM into Firefox?

Mike Shaver:

Here are a few, at least as I see them:

• Optimized to run JavaScript and sibling languages, which is our most important language target by a vast margin.
• Licensed appropriately.
• About 1/25 the size, I think (200KB for Tamarin, 5MB for Mono as described by Miguel elsewhere)
• In my coarse measurements, significantly smaller memory footprint.

I was once quite a supporter of getting Mono into our world, including writing a prototype XPCOM binding for it, but I didn’t see a path to getting the important factors (performance, licensing, footprint in code and memory) resolved, and I don’t think it’s much closer today. Nobody in Mono-land was interested enough to contribute to that, which is another counterpoint with Tamarin I suppose, where we have very active contributions from Adobe and others to help us get it in the state we need for it to be a suitable basis for building our whole app on.

It’s not like we didn’t look hard at Mono, and in the case of many of us lobby hard for licensing and patent concerns to be swept aside. Tamarin is a very good fit for us in a large number of ways, unfortunately including a number of ways in which Mono is not.

[Why doesn’t] Mozilla build on the Java platform rather than Tamarin?

Brendan Eich:

Moreover, for Mozilla at least, we absolutely cannot depend on closed source, and we require a non-copyleft BSD license, or at most MPL/GPL/LGPL. Java was not even open source until recently (I don’t remember the date; it was preannounced one too many times :-/), well after we had to make our own plans and commitments.

Finally, in spite of the prospects with JRuby, the JVM really is about Java first and last. Tamarin is about an ECMAScript variant, so it’s a better target now, and more likely to evolve to support JS1 and JS2 in a first class way, than the JVM.

Compilation heroics can help, but the browser will remain an environment where compilation must be very fast. Wherefore our forthcoming work on a trace-based JIT.

Then some commenters disagreed with the performance results, and claimed that a JVM would be faster but the benchmark was brought into question:

No contest indeed, Tamarin is optimized towards small footprint and instantaneous startup, compared to Hotspot. However, it can do better. If I add a return type annotation, and place a package {} declaration around the test (triggering early binding), Tamarin avoids boxing overhead, and the test results drop from 56s to 11s on my T60p, solidly inbetween Rhino-JS and pure Java.

Having a JIT running our JavaScript will be great step, however we get there.

Source: Ajaxian
Original Article: http://feeds.feedburner.com/~r/ajaxian/~3/142709246/the-choice-of-tamarin