Adobe and Mozilla Foundation Collaborate on ECMAScript

gemal writes "I just saw a project called Tamarin (AVM2 open source) Flash9_DotReleases_Branch initial revision checked into the Mozilla CVS repository. Shortly afterwards came the following press release: ' Adobe and the Mozilla Foundation today announced that Adobe has contributed source code for the ActionScript Virtual Machine, the powerful standards-based scripting language engine in Adobe Flash Player, to the Mozilla Foundation. Mozilla will host a new open source project, called Tamarin, to accelerate the development of this standards-based approach for creating rich and engaging Web applications. This is a major milestone in bringing together the broader HTML and Flash development communities around a common language, and empowering the creation of even more innovative applications in the Web 2.0 world.' You can read about the Tamarin project on the Mozilla site."

It can't be any worse than SpiderMonkey

[Anonymous Coward]

This is really great news, assuming Mozilla can get over their "Not Invented Here" syndrome (see: Linux distros required to verify their patches with Mozilla) and replace SpiderMonkey (the current Mozilla JS engine) with it. Almost all the problems people have with excessive CPU use are related to the JS engine. Firefox's backend uses a LOT of JavaScript (not kidding!) and it can greatly slow the browser down, especially when there are a lot of extensions running.

This is great news - assuming it replaces SpiderMonkey. The current JS engine in Mozilla is amazingly slow.

Re:Please add multithreading

[vaderhelmet]

My biggest complaint is the fact that it doesn't complete execution on a function before moving to the next. Having to estimate execution time, then using a timer to fire dependant functions is a pain. This would be much better if it were a "jump and link" situation.

JIT for javascript

[augustm]

Reading the various explanations on mozilla sites-
this will (one day) give a just in time compiler
and virtual machine for javascript in firefox.
This should lead to big speedups in many
web applications

Re:It can't be any worse than SpiderMonkey

[Anonymous Coward]

Because ActionScript IS JavaScript. Well, sort of - there are a number of extensions on top of it, but it's basically syntactic sugar. JavaScript and ActionScript use very similar backends.

The main thing that Adobe is providing is a virtual machine designed to run ActionScript and, with little modification, JavaScript as fast as possible.

The biggest slow down in Mozilla is its scripting interface. This should greatly help with that.

Request, Please.

[LifesABeach]

What are Mozilla's intentions now with respect to SVG [carto.net]? One can not ignore that the specification of SVG [w3.org] with respect to Adobe's Flash [adobe.com] product. To my thinking, SVG [slashdot.org], or its spawn, is the direction of future web developement.

Re:Holy crap

[Anonymous Coward]

Sheesh, but why do they have to keep reinventing the wheel? Why create some ECMAScript that no one has heard of? Why not just work on Javascript?? ;)

Re:If you need an ECMAScript parser....

[Anonymous Coward]

The file you linked to is an an ECMAScript parser. It's the bytecode parser -- Abc stands for ActionScript bytecode. Its the intermediate format that Adobe's compiler creates and stuffs into .swf files for execution. The virtual machien parses the bytecode and executes the instructions found.

The Tamarin project does not include Adobe's Java ECMAScript compiler used to create the abd block. Instead, it contains a "self hosting" compiler, located in this directory [mozilla.org]. Specifically, the ECMAScript parser, written in ActionScript, is here [mozilla.org]. This is explained in the FAQ.

ECMAScript...

[Bizzeh]

...needs a less stupid name

Re:Please add multithreading

[twofidyKidd]

I'm confused by this. It sounds like you're writing code like this:

function thisX(args){
SomeCode;
SomeCode;
thisX();
}

function thisY(args){
SomeCode;
thisY();
}

Where some function of thisY() is dependent on the execution of thisX(), except you're saying that thisX() runs slower than thisY(), so you write some sort of timeout to run thisY() after thisX has finished (by estimation, as you mentioned.)

Why don't you do this instead:

function thisX(args){
SomeCode;
SomeCode;
return Var;
}
function thisY(args){
SomeCode;
SomeVar = thisX(args);
}

Such that the complete execution of function thisY() is dependent on the complete execution of function thisX() without having to set some timeout and basically, make your code wait around with fingers crossed for the first function to execute? I'm surprised you got modded up for this, and no one checked you before. The only time I ever use timeouts is when I actually want the code to run on human time, like "wait 5 seconds before refreshing some section of the page, or before you display an alert" or something to that effect, but never for code dependency. The parent's complaint regarding multithreaded is directed toward this, but the workaround is not to "time" your code.

Then again, I could be way off base here, and I'm sure someone will "fix" me.