August 8th, 2007
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:
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.
Tags: vm, tamarin, mozilla, javascript, mono, ecmascript, java
11 Comments on 'Why Tamarin instead of...'
August 8th, 2007
In the bustle of announcements surrounding OSCON, Blackhat, and the Ajax Experience one single, incredibly important, announcement was made: The introduction of two new Mozilla projects: IronMonkey and ScreamingMonkey.
The critical, core, component of this is the Tamarin virtual machine (which is an Open Sourced version of the ActionScript Virtual Machine that powered the Adobe Flash Player). Tamarin already supports ECMAScript 3 (and, thusly, JavaScript, ActionScript, and JScript) and parts of the upcoming ECMAScript 4 specification.
Briefly, since they're both still under planning, here's what IronMonkey and ScreamingMonkey are setting out to achieve.
IronMonkey is setting out with the goal of mapping Microsoft's Common Intermediate Language (CIL) to ActionScript Byte Code (ABC), allowing additional language implementations, such as IronPython and IronRuby, to run in the Tamarin Virtual Machine.
IronPython and IronRuby are implementations of Python and Ruby, respectively, that runs on .NET Common Language Runtime (CLR) (and, incidentally, also on Mono), written in C#.
IronRuby is built on top of the Dynamic Language Runtime (DLR)... DLR will ship as part of the Common Language Runtime (CLR) in the future...
To break all of this down: There are implementations of Python and Ruby that are capable of being compiled down to a Common Intermediate Language, which will then be able to be run on Tamarin via IronMonkey.
This is a huge, huge, deal. This means that JavaScript will no longer be the only viable scripting language in browsers that use that Tamarin engine. At the very least, there'll be two more languages to work with. However, if IronMonkey works out well, I wouldn't be surprised if we see an implementation of PHP that runs in the browser.
Tamarin being able to run JavaScript 2, Python, and Ruby really doesn't mean a whole lot (to the general web-developer public) if the languages don't work in all modern browsers (even though it'll give development on the Mozilla platform a considerable boost). This is where ScreamingMonkey comes into play.
ScreamingMonkey is the effort, being led by Mark Hammond, to allow the Tamarin engine to run within non-Mozilla browsers, starting with Internet Explorer.
Unfortunately, the Internet Explorer team is caught up fixing bugs in their existing ECMAScript implementation (JScript), thus their likelihood of implementing ECMAScript 4, in a reasonable time frame, is slim to none.
The result of this effort will be for a developer to be able to reference ECMAScript 4 or JavaScript 2 from a script tag and have it load a required plugin in order to execute it, for example:
<script type="application/ecmascript;version=4">...
</script>
or:
<script type="application/javascript;version=2">...
</script>
There's a detailed plan of attack laid out and it will require a lot of work. The end result still needs to be actualized, but it will most likely be in the form of a standalone Tamarin runtime (possibly embedded in another distribution) that will be able to hook into its relevant browsers.
As with IronMonkey, this is a huge announcement. This immediately helps to give credence to using the upcoming JavaScript 2 language as its cross-browser support is practically assured. While we're still a long ways off from being able to use this particular project, the result of it will surely be incredible.
Regardless of the outcome of either one of these projects, it's obvious that browser scripting is beginning to shift in some appreciable ways. Although, should these projects succeed the resulting effect upon the web development industry will be incalculable.
Tags: ruby, python, javascript, ecmascript, tamarin, .net, mozilla
18 Comments on 'The Browser Scripting Revolution'
