Adobe and Mozilla Foundation Collaborate on ECMAScript 142
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."
Go open source go! (Score:1)
Open Source Compiler (Score:3, Informative)
Re:Go open source go! (Score:1)
My......God...... (Score:5, Funny)
This can't be a good thing. (Score:2, Insightful)
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. (Score:2, Insightful)
Re:This can't be a good thing. (Score:2, Informative)
Re:This can't be a good thing. (Score:2)
Re:This can't be a good thing. (Score:1, Offtopic)
Re:This can't be a good thing. (Score:2, Insightful)
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 [mozillazine.org]
Re:This can't be a good thing. (Score:1)
Also, I realize you're blaming the output and not the developers, but give the developers some credit here...
Light PDF parsers: XPDF and Foxit. (Score:2, Informative)
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:This can't be a good thing. (Score:1)
Re:This can't be a good thing. (Score:2)
uhhh (Score:2, Troll)
The unstated benefit: (Score:2)
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.
AJAX and Flash (Score:2)
Re:AJAX and Flash (Score:2)
Re:My......God...... (Score:2)
Don't worry too much, they're calling it part of the "Mozilla 2.0" project. They've got to break through the second system syndrome first.
(second-second system?)
Jumping the Gun (Score:2, Informative)
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 [osflash.org]): ECMAScript [wikipedia.org] 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
Re:Jumping the Gun (Score:5, Informative)
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 (Score:4, Insightful)
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.
Re:Jumping the Gun (Score:1)
Re:Jumping the Javascript Gun (Score:2)
Re:Jumping the Javascript Gun (Score:1)
Secondly, ECMAScript != JavaScript. JavaScript language is based on and compatible with ECMA specification but they are not the same. There are many different implementations of ECMAScript including Microsoft's JScript and Adobe's ActionScript.
Re:Jumping the Gun (Score:3, Informative)
Re:Jumping the Gun (Score:1, Informative)
Re:Jumping the Gun (Score:1)
First, ActionScript (not "Flash") is based on ECMAScript, not the other way around. And I'd say it's hard for ECMAScript to try and "emulate" Flash. The ECMAScript specs aren't created by Adobe, you know, but by several engineers from companies like Apple, Adobe, Microsoft, Opera, etc, with Mozilla in the lead.
Second, you've misunderstood the post, the press releases, and everything related to this news item. They're not open-sourcing the player. There's no "Flash Studio" (what?) libraries or features to be opened, and there's nothing for people to "code" like "normal effects".
This is not related to Flash. It's related to the ECMAScript virtual machine, and something Mozilla can directly benefit from since they use a similar VM for their JavaScript execution. If anything, having this properly applied (2008 on according to their roadmap) will make HTML (specially Ajax) sites faster on Mozilla browsers, and Mozilla's own execution, not Flash.
In sum, this is not the thread you're looking for.
Re:Jumping the Gun (Score:1)
ECMAScript != Flash (Score:2)
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.
Re:ECMAScript != Flash (Score:2)
If you need an ECMAScript parser.... (Score:4, Informative)
It looks like they rolled their own parser for Tamarin - AbcParse.cpp looks hand coded [mozilla.org] to me. Maybe that was more efficient than yacc?
Re:If you need an ECMAScript parser.... (Score:1, Interesting)
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.
Re:If you need an ECMAScript parser.... (Score:2)
Now, I think it just stands for... um... ABC.
(Maybe if they had chosen a monkey with a name starting with "A", the acronyms would have been more meaningful...)
Re:If you need an ECMAScript parser.... (Score:2)
Oh, you mean, _not_ an ECMAScript parser. But you're right, and thanks for the correction.
> the ECMAScript parser, written in ActionScript, is here.
Thanks for the pointer! Wow, looks like they hand-rolled this as well... that's a doozy.
Re:If you need an ECMAScript parser: OpenLaszlo (Score:2)
The OpenLaszlo [openlaszlo.org] compiler also has an ECMAScript parser, and it outputs Flash bytecode. The Legals Project [openlaszlo.org] 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 [openlaszlo.org] 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 [swig.org]! 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: [openlaszlo.org]
And evil hackers everywhere rejoice... (Score:1)
Re:And evil hackers everywhere rejoice... (Score:4, Insightful)
Re:And evil hackers everywhere rejoice... (Score:1)
Please add multithreading (Score:3, Insightful)
Re:Please add multithreading (Score:3, Interesting)
Re:Please add multithreading (Score:3, Interesting)
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:
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.
Re:Please add multithreading (Score:1)
And btw, Mozilla's JavaScript implementation does support multiple threads.
Re:Please add multithreading (Score:2)
JavaScript IN A WEB CONTEXT does not. That's a problem that's hard to solve without breaking lots of existing pages that assume the single-thread run-to-completion semantics and depend on it.
In Gecko, the DOM code is also effectively single-threaded. Changing that could be done, but would likely have significant performance impact...
Re:Please add multithreading (Score:2)
http://developer.mozilla.org/es4/proposals/iterat
A Step in a direction (Score:3, Informative)
Re:A Step in a direction (Score:2)
Comment removed (Score:2)
Re:A Step in a direction (Score:2)
Anyways... did you go to http://www.flashearth.com/ [flashearth.com]?
Also, Don't you know not to browse the web with your sound turned up? That's like keeping your TV volume up while watching the weather channel and then being surprised by a commercial when you change it to a normal station.
Re:A Step in a direction (Score:2)
Comment removed (Score:2)
It can't be any worse than SpiderMonkey (Score:2, Interesting)
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 (Score:2)
Re:It can't be any worse than SpiderMonkey (Score:5, Informative)
From Frank Hecker, executive director of the Mozilla Foundation, at http://www.hecker.org/mozilla/adobe-mozilla-and-ta marin [hecker.org]:
Linux distros required to include LOGO .. (Score:2)
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
Re:It can't be any worse than SpiderMonkey (Score:2)
By "related to" do you mean "there's some JS involved somewhere, possibly calling native code where lots of time is spent"? Or you mean "I've profiled it, and the time is spent in the JS engine"?
If you _haven't_ profiled it, then you're basically making assumptions that might or might not be right (but probably aren't, given most of the profiles of "JS is slow" bugs that I've seen -- in almost all cases the problem is actually in the DOM or layout code).
SpiderMonkey IS the worst, hands down. (Score:2)
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 [debian.org] 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
Re:SpiderMonkey IS the worst, hands down. (Score:2)
What you link to is not a profile, but a benchmark. Not the same thing at all.
And note that nowhere did I say that SpiderMonkey is a very fast programming language. It's not, of course. It's got its speed issues. Not having carefully read the exact source of the benchmark you quote, I can't tell you how much of the performance shown on that benchmark is due to innate slowness and how much is due to poorly-written code, but I suspect it's more of the former than the latter.
What I objected to was the claim by "Anonymous Coward" that "almost all" Mozilla performance problems are related to SpiderMonkey. Some are, most are not. Telling which is the case involves doing a profile (figuring out which parts of the code time is spent in). Just running a benchmark does NOT give you this information.
Re:It can't be any worse than SpiderMonkey (Score:2)
Re:It can't be any worse than SpiderMonkey (Score:1, Interesting)
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.
Re:It can't be any worse than SpiderMonkey (Score:2)
Typesaftey isn't syntactic sugar.
Javascript:
var foo = 3;
foo = "butts";//this is ok
Actionscript:
var foo:Number = 3;
foo = "butts";//this is a compile-time error
Re:It can't be any worse than SpiderMonkey (Score:2)
http://en.wikipedia.org/wiki/Syntactic_sugar [wikipedia.org]
i += 3 vs i = i + 3 is syntactic sugar. A switch that enforces type safety is something else.
Web 2.0... (Score:1)
There's a detailed commentary (Score:5, Informative)
JIT for javascript (Score:3, Interesting)
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:JIT for javascript (Score:2)
Am I just missing something? Is there some intermediary bytecode compilation for JS files that is then further enhanced for specific platforms by JIT? And if so, why the intermediary step (JS -> bytecode, bytecode -> machine code) in the browser?
Somebody please 'splain the advantage of dynamic translation for JS to me please?
Re:JIT for javascript (Score:2)
Re:JIT for javascript (Score:2)
So have I got this clear now? (Score:1, Insightful)
Re:So have I got this clear now? (Score:3, Insightful)
Yes. (Score:1)
Read these before you spread FUD (Score:5, Informative)
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 [mozilla.org]
Please read these before you post FUD. Oh wait... This is
Adobe needs to open the plugin's source... (Score:2)
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).
Re:Adobe needs to open the plugin's source... (Score:2)
It is true. Open a PDF "page" in your firefox (with the plugin), and use ps to see an instance of acroread...
Plugin and acroread communicate via a local domain socket (/tmp/a*). While it is possible to hack a "clean-room" implementation, the right thing to do is to get Adobe to release the official source. They don't have any "intellectual property" in the plugin — they should release its source for the benefit of all (Adobe included).
Take it easy (Score:5, Informative)
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.
Mod parent up! (Score:2)
Brendan Eich's blog [mozillazine.org]
Frank Hecker's blog [hecker.org]
Re:Take it easy (Score:2)
ActionScript and JavaScript are both extensions of ECMAScript 3. Mozilla and Adobe (among others) are working on an ECMAScript 4 specification that will incorporate many of the extensions, so I actually expect JavaScript and ActionScript to converge quite a bit over the next few years.
Note that I'm just talking about the programming languages, not the DOM for manipulating HTML/XML documents in Firefox or the APIs for manipulating movies and animations in Flash.
Request, Please. (Score:2, Interesting)
Re:Request, Please. (Score:2)
Re:Request, Please. (Score:2)
ECMAScript... (Score:2, Interesting)
Re:ECMAScript... (Score:1)
Re:ECMAScript... (Score:1)
Actionscript 100 times slower than qbasic (Score:2)
Re:Actionscript 100 times slower than qbasic (Score:2)
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?
With which version of the FlashPlayer did you do that test?
Tamarin is the VM introduced for FlashPlayer 9, aka. AVM2. The above sounds like you tested on AVM1, which is included in FP9 for backwards compatibility. AVM2/Tamarin is JIT compiled, and significantly faster than AVM1. If you want to test, you will need to specifically compile for it, either by using Adobe's free as in beer Flex SDK [adobe.com] if you like to use ActionScript 3, or haXe [haxe.org] for an open source alternative that has some aditional features.
Benchmarks (Score:3, Informative)
Mozarella Foundation (Score:1)
http://www.theinquirer.net/default.aspx?article=3
No 64 bit version (Score:2)
Yes, this is nice... (Score:1)
GREAT news for OpenLaszlo, Firefox and AJAX! (Score:4, Informative)
OpenLaszlo [openlaszlo.org]'s Legals Project [openlaszlo.org] 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 [debian.org], 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
Re:GREAT news for OpenLaszlo, Firefox and AJAX! (Score:2)
> to load pre-compiled binary bytecode into Firefox
Actually, that feature exists and is used in Firefox at startup. See http://lxr.mozilla.org/seamonkey/source/js/src/js
Now you can't do it from inside the JavaScript language. But any consumer of the C JSAPI can do this.
Re:GREAT news for OpenLaszlo, Firefox and AJAX! (Score:2)
I didn't realize that SpiderMonkey already had a way to load pre-compiled JavaScript code. Is there any reason it's not possible to allow web pages to download pre-compiled JavaScript byte code as well? That would really benefit AJAX applications.
For Firefox with the AVM3, the most obvious format to use for pre-compiled byte code would be SWF files, which contain codes for graphics as well as byte codes. Firefox could just ignore or trap on unsupported graphics codes. And then all the tools that support SWF files (like the OpenLaszlo compiler) could be applied to Firefox.
(Of course I don't mean JavaScript compiled into machine instructions (that's the job of the JIT), so the security of downloading uncompiled JavaScript text and precompiled binary JavaScript byte codes should be identical).
-Don
Re:GREAT news for OpenLaszlo, Firefox and AJAX! (Score:2)
> JavaScript byte code as well?
Probably not, except it involves freezing the bytecode format. The XDR format is not guaranteed stable across releases -- its primary purpose is effectively for a compiled-stuff cache, with fallback on the original script if the cache XDR version doesn't match the running version.
The title just changed! (Score:1, Informative)
Re:Holy crap (Score:1, Interesting)
Re:Holy crap (Score:1)
Dreamweaver and Fireworks use Netscape's javascript interpreter, and include the source code:
"Javascript Int Source Code.txt"
The original source code to the JavaScript Interpreter was provided by Netscape Communications Corporation and the modifications to the source code are derived, directly or indirectly, from such code. The changes to the original code from Netscape Communications Corporation are documented in the accompanying Readme file.
Re:Holy crap (Score:3, Insightful)
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.
Re:Holy crap (Score:1)
Re:Holy crap (Score:1)
Re:Holy crap (Score:2)