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."
Okay, so it's actually only a part of Flash. Still amazing, especially since Adobe just decided to use WebKit rather than Gecko for Apollo's rendering engine.
Go open source go! This is great news for us Linux geeks. :)
AJAX in Flash, with a Web 2.0 hype engine. May god have mercy on us all.
May the Maths Be with you!
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): 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
My work here is dung.
It was "Adobe and Mozilla to Open Source Flash" when it went live.
...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?
The Army reading list
tt the thought of yet another way to attack your web browser.
Javascripts single-threaded design is the biggest roadblock on the way to a web-app platform.
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.
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.
Hmmmm. CMP Media is driving this thing...or O'Riley Media? I'm so confused.
..on the issue by Mozilla Foundation's executive director: Frank Hecker's blog
Vote AGAINST Osama bin Laden's employer.
From an undisclosed, secure bunker far away from President-VICE Richard B. Cheney's spider-hole,
Kilgore Trout
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
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.
When Adobe does Flash its shit, bloated, resource hogging intrusiveness. When Mozilla does Flash its empowering and innovative.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
Here is the official Adobe Announcement:l eases/200611/110706Mozilla.html
e lative-tamarin-joins.html
/. FUD away. ;)
http://www.adobe.com/aboutadobe/pressroom/pressre
And here is a great blog post from Tinic, one of the Flash Player engineers:
http://www.kaourantin.net/2006/11/spidermonkeys-r
And the Tamarin FAQ:
http://www.mozilla.org/projects/tamarin/faq.html
Please read these before you post FUD. Oh wait... This is
Excuse me but isn't Gecko an implimentation of ECMAScript aka Javascript?
64-bit support is being worked on currently now that the source code is intended to be used in multiple products.
If and when this occurs, we could expect to see a 64-bit flash plugin (finally), as the main blocking factor was the ActionScript VM, according to developer blogs.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Especially — the Acrobat-plugin. You may not know this, but the plugin does little work other than spawning off an instance of acroread (a separate process). This means, they can keep their proprietary secrets intact, and open the source code of the plugin itself.
This would allow various BSDs, for example, which can all run Linux executables, to have the plugin in their natively-compiled browsers. Same goes for 64-bit browsers on Linux (64-bit plugin can spawn off the 32-bit executable). Even on Linux, where native plugins are supplied by Adobe, it would allow bolder changes in the browser/plugin APIs (changes that may break the ABI).
For example, Real has gone "all the way" and open-sourced their entire player (except for a few codecs). This allowed to fish out their plugin code, build it natively and use it with Real's own Linux executables (and full set of codecs), wherever that can run (such as FreeBSD/amd64).
In Soviet Washington the swamp drains you.
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.
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.
What are Mozilla's intentions now with respect to SVG? One can not ignore that the specification of SVG with respect to Adobe's Flash product. To my thinking, SVG, or its spawn, is the direction of future web developement.
The parent is clearly FUD, someone please mod it down, not up!
President Bush has DONE some of the points there, although the article says that it is only claimed he wants to do those (*cough* *state of fear + militarization* *coug* )
ECMAScript with support for VRML and related vector/plane graphics animation technology could compete with something like Flash, but I wouldn't call it a replacement.
I would call it a standards-based answer to Microsoft's clumsy attempt to create a competing "standard" that only runs on WinXX. FUD for FUD, the battle over market share continues to be about media mind share, not quality, performance, scalability, portability, or any other technical "issue". Heck, most of the FUD bombs launched aren't even demos, much less production products.
I do not fail; I succeed at finding out what does not work.
The /. summary is pretty worthless (is anyone surprised?). This is only related to Flash inasmuch as Flash has a JavaScript VM / JIT Compiler, and that technology has been released to Mozilla so that they can take advantage of those performance improvements. At least that's how I read the news from people actually involved.
Brendan Eich's blog
Frank Hecker's blog
Rock over London, Rock on Chicago. Wheaties: Breakfast of Champions.
...needs a less stupid name
portfolio
"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)"
They're free to use any patches as long as they don't call it Firefox. From what I can figure out it is a dispute over the use of the logo. Debian are happy to use the codebase they just don't want to include the logo. It's also not unreasonable for Mozilla to want to verify patches for Mozilla Firefox.
was Re:It can't be any worse than SpiderMonkey
davecb5620@gmail.com
Careful... I got in a massive flamewar with a guy from OpenLaszlo who was adamant that Flash applications are AJAX web applications, because they use asynchronous XML and JavaScript.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Obviously I'm stuck on KDE 3.3, because apparently 3.4 and 3.5 have versions of KPDF that can find text. I stand corrected.
LOAD "SIG",8,1
There is not a single web technology that rivals the pure evil and depravity of javascript and flash.
This is the first and most significant nail in Mozilla's coffin.
In my personal tests, Actionscript is over 100 times slower than Quickbasic. Why the hell is that the case? Both are interpreted languages. Actionscript even compiles to bytecode before it's executed, and I think Quickbasic does something similar as well. Does static typing alone really cause a language to run faster? Or is it just what happens when you design interpreters for high vs. low-specification processors?
The headline at inquirer reads "Adobe Hands Mozarella Foundation Flash Code"
5 584
http://www.theinquirer.net/default.aspx?article=3
I'm wondering if this will close some of the Javascript holes that Mozilla has been having recently?
Tamarin vs. SpiderMonkey 1.7.
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.
-Woof woof woof!
Why as a matter of fact, yes, somebody HAS profiled SpiderMonkey. And you might be interested in knowing just how fat and slow it is compared to other languages.
The Computer Language Shootout demonstrates that SpiderMonkey JavaScript is not only THE WORST language, in terms of BOTH slow speed and huge size, but also TWICE AS BAD AS THE SECOND WORST. SpiderMonkey loses the Computer Language Shootout by a long shot. Even bigger than the Republicans are going to lose this election!
So the assumption that SpiderMonkey is fat and slow is extremely correct, by a long shot. Just like the assumption that the Republicans are corrupt and incompetent.
-Don
Take a look and feel free: http://www.PieMenu.com
...but when can I have it for IE6 and/or IE7?
How would someone new to the idea get an introduction to profiling which specific functionality of a program at a given time required the most CPU power (or RAM, video, HD read time, etc?)?
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
Take a look and feel free: http://www.PieMenu.com
The OpenLaszlo compiler also has an ECMAScript parser, and it outputs Flash bytecode. The Legals Project will support the AMV3 runtime, which Adobe just made Open Source and Mozilla will be incorporated into Firefox.
Adobe open sourcing AVM3 and Firefox incorporating it is great news for OpenLaszlo, because it dovetails so nicely with the roadmap already in place!
Opening up AVM3 also enables the development of open source debuggers and integrated development environments like Eclipse, and makes it possible to embed an efficient JavaScript engine into any application, which has enormous long term benefits for everyone.
Please, I beg: somebody write an AVM2 back-end for SWIG! That would totally rock. It's an essential tool for wrapping libraries and extending languages, that SpiderMonkey's sorely missing.
-Don
From the OpenLaszlo Project Legals FAQ:
Take a look and feel free: http://www.PieMenu.com
Yes.
I hope it will be soon in the Computer Language Shootout.
It is jit based dynamic language VM so, could it be used to implement Perl/Python/Ruby?
now THAT would be an application.
Flash is free in the way that Adobe is free to change anything about it whenever it feels like it.
I stick to free video formats and SVG
i didn't install noscript for nothing!
Flash is just a sneaky way of implementing a form of DRM for Web documents, since it can hide or obfuscate source files that would otherwise have been directly accessible under good old HTML. The real "Web 2.0" is one we need to WORRY about and fear, not herald... the real Web 2.0 will be one based upon information-restrictive technologies like Flash. HTML was designed with "open source" in mind... can any form of Flash-like Web interface ever truly be called open source? Do we really want to continue to encourage this form of Web design? Personally, I avoid any Web site which is entirely designed with Flash.
Click on the dialog box to start!
The ECMA script documents contain Microsoft Patented technology, and if you use te documents, you have to license the technology from Microsoft for Money. ECMA is a patent troll trap, BEWARE.