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."

Comments

My......God......

[ObsessiveMathsFreak]

AJAX in Flash, with a Web 2.0 hype engine. May god have mercy on us all.

Jumping the Gun

[eldavojohn]

I just saw a project called Tamarin (AVM2 open source) Flash9_DotReleases_Branch initial revision checked into the Mozilla CVS repository.

While you may know more than you put in the summary, I suspect you are jumping the gun here. The fact that a Flash9_DotReleases_Branch tag shows up in an open source CVS repository is certainly no reason to infer that they will "open source Flash." Perhaps that tag referred to a point at which the project was compatible/comparable with Flash 9?

In fact, after reading the project site, nowhere do they claim to be trying to open up Flash. Instead, it looks like they're going to re-implement the engine (tried before):

The goal of the "Tamarin" project is to implement a high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification.

ECMAScript version four is the language used by Flash, buy it could possibly be a derivative of Flash or an attempt to emulate Flash. Flex is an example of Adobe coaxing developers to use MXML and ActionScript and I suspect that this open source engine is no different. I imagine that it will lack the libraries and features of the licensed Flash Studio so that the developers will have to code a lot of the normal effect engines from scratch. Net effect, developers are given a little more freedom in coding and Adobe becomes the standard like they did with PDF. It looks like they're losing money on Studio licenses but instead they're cementing their stake in technology by offering basic services free and premium services at a ... well ... premium. Similar to what Google is doing and what Microsoft is learning. You know, like a heroin dealer the first few tricks are free but to get extra you gotta pony up.

Re:Jumping the Gun

[Anonymous Coward]

You're incorrect. See this blog entry from an Flash Player engineer: http://www.kaourantin.net/2006/11/spidermonkeys-re lative-tamarin-joins.html

It is not an attempt to re-implement the ActionScript Virtual Machine (runtime). It *is* the ActionScript Virtual Machine. Adobe and Mozilla are working together to build a common runtime, that already exists in Flash Player 9 and is already ECMAScript 4 compliant. Adobe just saved Mozilla a lot of time and hassle by giving them a high performance virtual machine that already implements the ECMAScript 4 spec.

Any changes Mozilla makes will find its way into the Flash Player. Any changes Adobe makes will find its way into Firefox.

Re:Jumping the Gun

[coyote4til7]

Where did you read "open source flash"? The whole Slashdot summary and the linked project page all refer to ECMAScript, aka ActionScript, aka Javascript. The linked project page makes it pretty clear that Mozilla and Adobe plan to use the Tamarin project as they basis of JavaScript (in Mozilla projects) and the ActionScript _portion_ of the Flash Player. RTFSS (RTF Slashdot Summary) before inserting foot in mouth.

Re:Jumping the Gun

[99BottlesOfBeerInMyF]

Sorry dude, I've stopped believing blogs as most of them (including Linux on the Wii) are nothing but lies and hoaxes.

It's one thing not to believe a random blog when it makes weird claims. It's another not to believe a blog from the person doing the work, when it is an expected move and is what the company talked about doing months ago. After the Adobe/Macromedia merger, Adobe stated they were working to integrate PDF (an open standard) and Flash to make for better, interactive Web functionality and that they planned to make the system open to encourage open source adoption.

If you need an ECMAScript parser....

[tcopeland]

...check out the Dojo project's JavaCC ECMAScript grammar.

It looks like they rolled their own parser for Tamarin - AbcParse.cpp looks hand coded to me. Maybe that was more efficient than yacc?

Please add multithreading

[Anonymous Coward]

Javascripts single-threaded design is the biggest roadblock on the way to a web-app platform.

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.

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.

A Step in a direction

[vaderhelmet]

I'm not a huge fan of Flash in general. It is too much like FrontPage... A thousand script kiddies to every 1 intelligent user. However, I believe a closer interaction and level of support for scripting languages that are shared between standard HTML pages and embedded objects will simplify (and hopefully speed up) development. ECMA Script is a very powerful tool in the right hands and Flash has some very interesting capabilities when paired with the Flash Media Server or Red5 (OSS) My 7 cents.

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:It can't be any worse than SpiderMonkey

[Rescate]

From Frank Hecker, executive director of the Mozilla Foundation, at http://www.hecker.org/mozilla/adobe-mozilla-and-ta marin:

The current SpiderMonkey JavaScript engine (used in Firefox, etc.) will not be replaced, as it does more than just provide a virtual machine; rather the Tamarin code will be integrated into SpiderMonkey. On compilers, the current SpiderMonkey engine can convert JavaScript to byte code, but does not have the ability to convert byte code to native machine instructions; this is a major feature that Tamarin provides. I don't know enough to comment on relative code quality; I'll leave this to others who've actually had experience with both code bases.

There's a detailed commentary

[henni16]

..on the issue by Mozilla Foundation's executive director: Frank Hecker's blog

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

This can't be a good thing.

[Anonymous Coward]

You're correct, this really can't be a good thing. Adobe and Mozilla are both companies that, in my experience, tend to put out extremely bloated and unstable software packages. And they do this for software that should be agile, and have a relatively low footprint.

I like to compare their products to similar ones developed by the KDE community. Take KPDF, for instance. It manages to be much faster and more stable than Adobe's Acrobat Reader, yet performs the very same functionality. And I'm sure we've all experienced Acrobat Reader's plugin interacting poorly with various web browsers, including both Internet Explorer and Firefox. There was even that recent problem where it would pop up a modal dialog box behind the main Firefox window, thus rendering it inaccessible, and basically locking up Firefox.

Then we can compare the Mozilla Project's Seamonkey and Firefox browsers to KDE's Konqueror. Konqueror proves to be lean, fast, and memory-efficient. Meanwhile, we routinely hear reports of memory leaks (often blamed on bad extensions or poor caching policies) causing Firefox processes to consume hundreds of MB of RAM. The few times that I have used Firefox, I have run into problems with it crashing.

When two companies with that sort of a track record for putting out bloated, unstable software get together to collaborate, I can't help but think the outcome will be quite poor. At least we do have alternatives, such as KDE. It's those alternatives that I'll continue to use.

Re:This can't be a good thing.

[Maian]

I won't deny that it may result in more memory usage, but the virtual machine would make Mozilla's JavaScript engine faster [1]. And remember that JS is extensively used in Mozilla's GUI, and in fact, they intend to migrate more non-critical C++ code to JS in the future (for faster development, security, etc.).

[1] http://weblogs.mozillazine.org/roadmap/archives/20 06/11/project_tamarin.html

Read these before you spread FUD

[md17]

Here is the official Adobe Announcement:
http://www.adobe.com/aboutadobe/pressroom/pressrel eases/200611/110706Mozilla.html

And here is a great blog post from Tinic, one of the Flash Player engineers:
http://www.kaourantin.net/2006/11/spidermonkeys-re lative-tamarin-joins.html

And the Tamarin FAQ:
http://www.mozilla.org/projects/tamarin/faq.html

Please read these before you post FUD. Oh wait... This is /. FUD away. ;)

Open Source Compiler

[mjbkinx]

The ActionScript compiler isn't open source (but available for free as in beer), but haXe is. It's not ECMA262 v4, but a relative with some additional goodies, like its type system. It can compile for FlashPlayer 9, among other platforms, which uses the VM now known as Tamarin.

Re:And evil hackers everywhere rejoice...

[starwed]

Actually, at the end of the day this sounds like it will increase security. Since Adobe and Mozilla plan to share exactly the same codebase, whereas now they maintain them seperately, that's one less surface to attack. And presumably having more people working on the same thing can't harm security either.

Re:So have I got this clear now?

[starwed]

No, you don't have this clear. This doesn't have much to do with flash at all. The only thing entering the mozilla code base is an EMCAscript VM. Flash will also use the same VM, and they'll enhance/maintain that VM jointly.

Take it easy

[springMute]

Just because I know people will jump the gut and make comments totally unrelated to this news just so they have something to bitch about, here's what Mike (One of the lead Linux engineers at Adobe) had to say:

Today, Adobe released the source for its ActionScript Virtual Machine to the Mozilla Foundation.

That's what Adobe did. Since this blog is a common stop for open source-minded folk, I thought it might be pertinent to use this space to discuss what Adobe didn't do:

        * Adobe did not open source the Flash Player.
        * Adobe did not incorporate the Flash Player into Mozilla.
        * Adobe did not license Mozilla's HTML rendering engine.
        * Adobe did not purchase Mozilla, or vice versa.

The project is specified by the name Tamarin, as in the monkey, in keeping with Mozilla's primate-naming conventions. Fun fact: Adobe is contributing around 135 KLOC (thousands of lines of code) of source code to the Tamarin project. So, in the grand tradition of open source collaboration, I invite you to jump right in.

Also see Tinic Uro's blog for more information.

This is not related to porting or open-sourcing Flash at all. It's all about ECMAScript, which is what JavaScript and ActionScript uses. This doesn't mean Mozilla will support ActionScript either, as it's just the virtual machine that's being opened, not the 'internal' functionality.

ECMAScript...

[Bizzeh]

...needs a less stupid name

Benchmarks

[mjbkinx]

Tamarin vs. SpiderMonkey 1.7.

Light PDF parsers: XPDF and Foxit.

[Tei]

Take KPDF, for instance. It manages to be much faster and more stable than Adobe's Acrobat Reader, yet performs the very same functionality.

I disagree. KDPF is really nice, and the next version will be impresive. But still theres minimal support for some advanced features, like scripting. Yea, only a subset of users need some byzarre features like that one, but still.. seems that adobe support a lot of these, maybe 99% of what PDF mean.
As a example (scripting) you need a javascript engine, maybe Spidermonkey, and add it to KPDF. Theres actually no javascript engine on KPDF, and adding spidermonkey is somewhat easy, but still is some work to do.

Seems... that is reallly hard to create a good parsing engine for pdf. This why KPDF is based on XPDF and theres only a few PDF viewers. And once you can parse a PDF file and render simple stuff, is enough for 90% of people. But theres still that 10% that use advanced features, that need HUGE ammounts to work.

I only know 3 pdf engines:

  - XPDF engine (that KPDF and Evince use). Fast but not complete.
  - Foxit engine. Fast but not complete.
  - Adobe engine. Slow but complete.

Once you add more features to a application. You need to do more stuff on startup. Maybe init some static arrays, load and parse config files, dynamically call more librarys that also need build stuff...

Imho, theres out here a engineer on Adobe that is frustrated because Adobe reader at core is lighting fast, but all the CRAP that need to load slowdown the whole thing to the actual mud-style.

note to self: Ask the Okula developpers to support CBR.

Re:Holy crap

[Fordiman]

It's called an update. Most likely, legacy ECMAScript (the 'JavaScript' you've been using since 1999, per ECMA-262) will work just as it always has. My guess is that Tamarin is going to have speed and syntax optimizations.

Honestly. You're probably one of the guys who claim that "Javascript isn't programming". Eh. Maybe I shouldn't assume things.

Still, the point is that the ECMA spec for inline browser c-like scripting has been updated at least three times since its standardization in 1999. Did you know that you can do Javascript in an object-oriented manner? Did you know that Flash's ActionScript is just ECMAScript with additional bindings (so is ColdFusions cfScript language)? How about the fact that you can pass inline functions as arguments? Have you ever used the "with" statement? Do you know DOM level 1? XMLHttpRequest? The 'in' clause in 'for'? Prototyped classes?

No, seriously, there's a lot more to Javascript than there used to be, and if you figure out the more advanced features (and how to properly separate behavior, presentation and content), it's actually a pleasant language to work in. I for one welcome the updates and additions to the language that can give 2008's webpages the kick they deserve.

GREAT news for OpenLaszlo, Firefox and AJAX!

[SimHacker]

OpenLaszlo's Legals Project will benefit immensely from this, because the OpenLaszlo compiler will directly target the AVM2 virtual machine that was just released as Open Source! Thanks to AVM2, Firefox will be a much better AJAX application delivery and development platform. OpenLaszlo is in a position to take excellent advantage of that, for the benifit of users as well as developers. Not only will AVM2 make OpenLaszlo applications run faster on Firefox, but opening up the AVM2 virtual machine will make it possible to develop much more powerful debuggers and integrated development environments.

All AJAX applications running on Firefox benefit, but Firefox itself will also benefit from integrating AVM2, because so much of FireFox is written in JavaScript itself.

AVM2 will be a huge improvement, because Firefox's current JavaScript interpreter, SpiderMonkey, is so extremely inefficient and wasteful of memory, that not only does it come in last in the computer language shootout, but it's actually TWICE as band and the next worst language, Smalltalk! (That's REALLY BAD.)

An important feature currently missing from Firefox that I'm looking forward to is a way to load pre-compiled binary bytecode into Firefox (like SWF9 files but without the graphics), instead of parsing and re-compiling the JavaScript source text every time. That's one of Flash's major advantages over browser-based JavaScript: it can quickly load and run pre-compiled AJAX applications much faster, thanks to the fact that it doesn't have to parse and compile huge amounts of JavaScript source code text files every time it starts up.

-Don

What is OpenLaszlo "Legals"?

"Legals" is an OpenLaszlo project to provide a single application environment that supports multiple deployment runtimes. OpenLaszlo 3.x supports Flash 7 and 8 now, but Legals will extend that reach to include DHTML as well as Flash 9. And with the necessary infrastructure in place, we anticipate further runtimes will be developed by the OpenLaszlo community.

The OpenLaszlo "Legals" project began at the start of 2006. We are projecting final availability by the end of the year. Developers interested in helping make Legals a reality are invited to contact us. Developers wishing to get a head-start building applications on top of Legals will be able to do so with our beta release in a few months.

Many people ask about the back story for the project name. The name, Legals, is a tribute to a well-known local restaurant in Boston where a lunch meeting inspired the team to launch this project.

See Legals FAQ for commonly asked questions and answers.

The Architecture

With Legals, the OpenLaszlo architecture is being remodularized into a true multi-runtime platform. OpenLaszlo generates script source that is compatible with ECMAScript Release 3, while leveraging extensions from ECMAScript Release 4. From there, multiple compiler backends generate JavaScript in the native dialect of the destination runtime: ActionScript 2 or 3, JScript 5.6, JavaScript 1.4+, and so on.

The OpenLaszlo runtime library is being refactored into two parts: multiple kernels containing runtime-specific code, and a cross-runtime library written in standard ECMA-3. As part of the runtime library, the OpenLaszlo class system has been rewritten in ECMA-3 and includes several innovative new features.

The OpenLaszlo runtime library delivers a common baseline of functionality across all supported runtimes. This gives the developer a rich environment in which to build full-featured web applications. In addition, Legals will include runtime-specific extensions so t