After yesterday’s post on the browser scripting revolution, detailing the new projects being built on top of Tamarin, a number of questions came up concerning the choice of Tamarin instead of other virtual machines. Two engines came up, in particular: The Java Virtual Machine (JVM) – which is already able to run Jython and JRuby, and Mono – which is able to run IronPython and IronRuby.

I’ll defer to the words of Mike Shaver and Brendan Eich to explain the reasons as to why, though 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.

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.

Brendan Eich: