Slashdot Mirror
Implications of the Mozilla/Adobe Partnership
Fraggle writes "Recently the Mozilla Foundation and Adobe announced a partnership, working together on the next generation
JavaScript/ActionScript JIT Virtual Machine. The Browser Den looks at what this means for the future of scripting in Mozilla, and how this partnership with Adobe may affect Mozilla's support for other technologies such as SVG." From the article: "On the Mozilla side the plan is to integrate to code with SpiderMonkey which is Mozilla's current JavaScript implementation that is written in C. This is needed because Tamarin is not a drop-in replacement for SpiderMonkey as it provides necessary features that are not available in Tamarin. The combined SpiderMonkey with integrated Tamarin should not have any problems with old JavaScript and should show a performance boost for most. However, skilled scripters are sure to find ways of optimising performance to get even more gains."
Tamarin has a JIT compiler for faster execution of a lot of Javascript code. I imagine that is a big part of what is going to be intergrated.
They basically mean combine SpiderMonkey's JavaScript compiler with Tamarin's JIT. So SpiderMonkey ends up compiling the JavaScript code down to some kind of intermediate format (which it already does), feeds that to Tamarin, which generates native code from that.
It's kind of like the LLVM project's C++ compilers - they took GCC, and modified it to produce LLVM bytecode which could be fed into their own JIT.
At the ajax experience Brendan Eich spoke about this and without mentioning company names. The boost in performance in JS will cement web application's future and will bring javascript to the forefront even more as the power language that it is. Combine that with JSON and the module tag proposal, it should be some very interesting times.
For those who don't follow the project tightly, there are indeed a slew of implications.
.NET or Java runtime. Or well, Adobe wants you to think that.
On the side of Mozilla, it means much faster, JIT JS engine, and since you know that Firefox's XUL depends heavily on JS to run, it may have big impact on the performance of Firefox as a whole and change the perception some have of Firefox as "bloated" and "slow".
This is just a guess though. Here's what's really fun.
Adobe is now working on its next generation "web platform", code named Apollo. Apollo's long term goals are to merge Flash, HTML/JS/CSS and PDF in one single "web platform", for internet applications.
Apollo is not a browser, you can think of it sort of like the
The first version of Apollo is not going to merge all three technologies into one, but it'll integrate them to work together. This means, you can have Apollo app that is based on AJAX with flash in it. Or Flash project with HTML in it. Or, I guess, Flash with PDF in it.. All sorts of combinations.
Adobe announced that they will NOT develop a browser on their own for Apollo, and that they are researching what to use.
I'll be honest, I thought it's apparent they'll pick Opera. Opera is faster than Firefox, it's portable to mobile platforms (and this is important to Adobe), and both Macromedia and Adobe have rich partnership with Opera already.
For example, Dreamweaver's WYSIWYG on Mac used to be Opera for a long time, and maybe it still is (on Windows, as far as I know, it's custom built).
And even now, the entire help system of Adobe uses built-in Opera browser. Even their "Bridge" image browser, is in fast running on Opera.
But now, as they contribute big chunks of Flash 9 (the script engine) to Mozilla, it means only one thing: Adobe has decided on a browser.
Apollo will feature a version of Gecko with Tamarin for a script engine.
Currently Adobe Reader (PDF) uses SpiderMonkey for its script engine, but when Tamarin is good enough to replace SpikerMonkey in Firefox, it'll be good enough to do it in Adobe Reader.
Hence, one step forward towards Adobe's vision of unified HTML/Flash/PDF platform. Interesting times.
I'm a huge fan of SVG. Not because it's a replacement for Flash, but because it's just XML, which means you can create data-based SVG images "out of thin air" with PHP or the scripting language of your choice. But now that Adobe has bought Macromedia (and with it, Flash) it looks like they're going to give up on SVG. I'm sure their apps will let you save as SVG, but they're going to quit supporting the viewer on 1/1/2008. And theirs was the dominant viewer. Mozilla has native support, and Safari is getting it, but that's nowhere near the adoption rate of MSIE or Flash.*
I was really hoping that they'd go the other way--that with the purchase of Macromedia, they'd roll SVG support into the hugely popular Flash plug-in. I wish I were wrong, but my guess is that Adobe, just like MS or anyone else, would rather back a proprietary solution (that they own) than an open one.
* and, the funny thing is, the MSIE/Adobe combination--on Mac and Windows--was the best. You could print a page with lots of embedded SVG images, and it worked! Safari with Adobe's plugin, or Mozilla with the plugin or natively, would print each image on a separate page, if at all. (Though I haven't tested FF 2.0 yet.) But MSIE/Adobe printed just as you saw on screen.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
I can open up an .swf in notepad and see the source?
I can inline flash elements in my (x)html page?
I'm allowed to write my own viewer for it?
BTW... Konqueror has good support for non-animated/non-scripted SVG already. Soon, it will fix those flaws as well. Webkit has about the same level of support, and there's a committment to make SVG a first-class image format for pages. Opera's support is stellar, including the animation/scripting parts. And Firefox isn't too shabby either.
As far as I know, that's all 4 major web browsers, and all those others that are based on their engines. I doubt SVG is going anywhere, except up. Die flash, die.