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

Is Open Source finally ready for prime time?

First the Novell/Microsoft deal and now this?

Amazing

Never in my wildest pre-crash dreams did I ever think that Javascript would become a respectable programming language.

HTML either, but that preconception was crushed when I saw the money those art school dropouts were making.

I just hope that they don't embed Flash player into the browser. That would suck royally.

There goes the neighborhood

Oh well, what's the next killer open source app that we use to thumb our noses at the man? This one's been assimilated.

Say What?

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.

I presume the article means to say that the Tamarin engine will be coupled with SpiderMonkey's APIs? Because I don't see how you could "combine" two separate Javascript engines and expect a usable result. That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.

Re:Say What?

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.

Re:Say What?

That would be like "combining" Windows and Mac OS X to make a better operating system. It doesn't quite work that way.

That sound you hear is the thousands of Microsoft Windows programmers kicking the dirt and going back to the drawing board.

Slashdot

Conspiracy Theories for nerds.

Will this ever see the light of day?

What I want to know is when will we actually see any benefits from this?

From TFA:

Tamarin is expected to make its Mozilla debut with Mozilla 2. Mozilla 2 is not actually a product release but is the version of the underlying framework. Mozilla 2 is not expected to be ready by 2008 at the earliest. Firefox 3 will be based on the Mozilla 1.9 framework, it is not sure at this time which Firefox release will use the Mozilla 2 framework.

So we have FX 3 being based on Mozilla 1.9 which means it will most likely be at least FX 3.5/4 (depending on the naming convention). Which means there isn't going to be a release that uses this until sometime between the tail end of 2008 and 2010.

I know there is going to be some serious amount of work involved but 2-4 years? That's a lot of technology advances...

Reviewing this should be done with an eye to GPLv3

Whether the deal is good or bad, or partly good and partly bad, it is a good example for thinking about what patent protections should be in GPLv3 [fsfe.org].

A good focus for the discussion, IMO.

However, skilled scripters are sure to..

However, skilled scripters are sure to find ways of optimising performance to get even more gains."

Like having Samy as your hero.

First post !

With Tamarin, FireFox will be faster... "First post !" for sure. ;)

Good news

At the ajax experience [theajaxexperience.com] 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 [json.org] and the module tag [json.org] proposal, it should be some very interesting times.

Lots and lots of implications

For those who don't follow the project tightly, there are indeed a slew of implications.

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 .NET or Java runtime. Or well, Adobe wants you to think that.

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.

Re:Lots and lots of implications

Actually, it has been anounced [blogs.com] that Apollo will be based on WebKit, the framework that is behind Apple's Safari. They will be using the open source version rather than Apple's internal version, but the differences are minor.

Credible OSS response to .NET (on the desktop)

Despite all the harping, .NET has been a huge success for Microsoft in Corporate/Server development. On the desktop, just as MS is afraid of Flash and Firefox (not coincidental or surprising they linked up) obviating the need for , I think Adobe, et al have been concerned about the potential impact of WPF, etc. for what they call the RIA [kotay.com] space.

Some early benchmarks [kotay.com] comparing SpiderMonkey, what would become Tamarin, and JScript.NET. are on my site [kotay.com]... interesting is that neither CLR, nor Tamarin provide a big boost when you use the features of JavaScript that make it more interesting than just plain old C. Wonder how much a real world boost this will be for the integration complexity? (i.e. is this another Netscape 6? Perhaps buckling down and fixing SpiderMonkey might serve better...)
--
graphically speaking [kotay.com]

About SVG

From TFA

I've seen some theories on the Internet suggest that part of the deal with Adobe was to remove the native SVG support from Firefox effectively reducing the competition for Flash.

There's no need for Adobe to make such a deal. Anyone who has tried using SVG on Firefox knows that the code renders so slowly as to be almost unusable, and lacks support for a tremendous number of SVG features. On top of that Adobe's own staff were always the big force behind SVG, now that Adobe has pulled out of SVG development its safe to say that SVG has no future outside of the tiny community of inkscape users.

The only way I could see them removing SVG support would be if Adobe ever decided to open source the Flash player but even then I could imagine that this would not be a popular move as SVG is an open standard.

Aside from the video codecs--which are no doubt entangled in far too many patent issues for Adobe to publish the standards--Flash is just as open as SVG, and it's a shame that open standards pundits refuse to stop pretending otherwise. It makes them sound just as stupid as the HD-DVD evangelists who pretend that HD-DVD is any less proprietary than Blu-Ray, and its hard to convince people that standards-based web development is important when this kind of garbage keeps getting spewed out.

SVG will eventually get yanked from Firefox not because of sleazy deals between Adobe and the Mozilla foundation, but due to the W3C not being behind SVG, SVG not having enough developers, the majority of SVG content on the web being experimental projects, and lack of software support for animated SVG content.

not so sure about SVG

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. [adobe.com] 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.

What javaScript needs

What javaScript needs is optional strong typing and name spaces. If it is to move forward for ajax applications.

good news and bad news

just thought i'd state the obvious...

good points are that if the co-operation meant better compatability, (if i made a site in go-live then it would definately work in firefox, or firefox could be made to adapt to go-live standard content) then i'd be happy!

bad news could be that firefox becomes closed source, and this could be a precursor to a buy-out. first, adobe are tempting the execs, getting friendly, and showing them what substantial funding culminates to... then deciding that, somehow, a coroporate merging would be a good idea...

just a thought...