Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Adobe and Mozilla Foundation Collaborate on ECMAScript

Zonk posted more than 7 years ago | from the shiny-happy-pengins dept.

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

cancel ×

142 comments

Holy crap (0)

Anonymous Coward | more than 7 years ago | (#16750935)

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.

The title just changed! (1, Informative)

Anonymous Coward | more than 7 years ago | (#16750971)

It was "Adobe and Mozilla to Open Source Flash" when it went live.

Help Democracy: +1, Inspirational (0, Informative)

Anonymous Coward | more than 7 years ago | (#16751131)


Vote AGAINST Osama bin Laden's employer [whitehouse.org] .

From an undisclosed, secure bunker far away from President-VICE Richard B. Cheney's spider-hole [whitehouse.org] ,
Kilgore Trout

Re:Holy crap (1, Interesting)

Anonymous Coward | more than 7 years ago | (#16751515)

Sheesh, but why do they have to keep reinventing the wheel? Why create some ECMAScript that no one has heard of? Why not just work on Javascript?? ;)

Re:Holy crap (1)

larry bagina (561269) | more than 7 years ago | (#16752817)

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 (0)

Anonymous Coward | more than 7 years ago | (#16755081)

It's basically what Macromedia did some time ago with ActionScript 1.0 - they tried make it more to the ECMAScript specs. It was easier to jump in for the AS 1.0 devs, it had more features, esp. regarding OO programming, but it sucked in terms of being confusing to the non-ActionScript developers, as well as being simply slow. It also had a lot of weird flash-only depreciated or simply stupid dependencies that annoyed their customers. That's why AS 3.0 came with a completely new, ES4 compliant engine. It's basically like saying 'bye bye to scripting and welcoming programming'.

So if you worked more on 'archaic' JS engine you'd end up exactly like macromedia - bloating everything.

Re:Holy crap (2, Insightful)

Fordiman (689627) | more than 7 years ago | (#16755363)

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.

Re:Holy crap (0)

Anonymous Coward | more than 7 years ago | (#16754449)

Still amazing, especially since Adobe just decided to use WebKit rather than Gecko for Apollo's rendering engine.

No comercial product uses Gecko. It's a completely fucked-up mess, supporting arbitrary parts of SVG and CSS, all very half-assedly. The fact that companies rather spend millions in licensing good engines (Opera, WebKit) rather than trying to patch a piece of crap like Gecko should give the Firefox-zealots reason to think (of course, they will ignore these facts).

Go open source go! (1)

AxXium (964226) | more than 7 years ago | (#16750953)

Go open source go! This is great news for us Linux geeks. :)

Open Source Compiler (2, Informative)

mjbkinx (800231) | more than 7 years ago | (#16751373)

The ActionScript compiler isn't open source (but available for free as in beer), but haXe [haxe.org] 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.

My......God...... (5, Funny)

ObsessiveMathsFreak (773371) | more than 7 years ago | (#16750957)

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

Re:My......God...... (0)

Anonymous Coward | more than 7 years ago | (#16751187)

ECMAScript on top of n-tier application server technologies makes it easy to leverage AJAX technologies to create a seamless feature rich Web2.0 experience for our users! Then we can all run our desktops in the browser and be free! Free I say!

This can't be a good thing. (2, Insightful)

Anonymous Coward | more than 7 years ago | (#16751213)

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. (1, Insightful)

strider44 (650833) | more than 7 years ago | (#16751799)

The reason why I use firefox instead of konqueror is simple: In firefox I have all the toolbars and required info including menus, navagation buttons and a bar, in one toolbar up the top. Konqueror doesn't yet allow me to do this. I think Konqueror's KHTML is quite neat in programming, but its user interface could still use some work.

Re:This can't be a good thing. (1, Informative)

mad.frog (525085) | more than 7 years ago | (#16752659)

Perhaps you should look at the code before calling it bloated.

Re:This can't be a good thing. (0, Offtopic)

Ant P. (974313) | more than 7 years ago | (#16752749)

I'd use Konqueror, but Firefox has certain things [kde.org] I can't live without.

Re:This can't be a good thing. (0, Flamebait)

Nasarius (593729) | more than 7 years ago | (#16752839)

KPDF has the same functionality as Adobe Reader? Surely you jest. It doesn't even have a search function. I love KDE and all, but I still have to use acroread to do my work.

uhhh (1, Troll)

Nasarius (593729) | more than 7 years ago | (#16752971)

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.

Re:uhhh (0)

stuckinarut (891702) | more than 7 years ago | (#16754293)

Ouch! You send two reasonable posts IMO and you get flamebait and troll, karma gets a hammering. Where's some mod points when you need them?

Re:This can't be a good thing. (2, Insightful)

Maian (887886) | more than 7 years ago | (#16752949)

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. (1)

xENoLocO (773565) | more than 7 years ago | (#16754015)

And the rest of us will continue to live in the real world, where things like convenience and corporate product support matter. Not to mention bad markup.

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. (2, Informative)

Tei (520358) | more than 7 years ago | (#16755117)

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.

The unstated benefit: (1)

Ayanami Rei (621112) | more than 7 years ago | (#16751331)

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.

AJAX and Flash (1)

metamatic (202216) | more than 7 years ago | (#16752409)

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.

Re:AJAX and Flash (1)

Metaphorically (841874) | more than 7 years ago | (#16754491)

Everybody wants a crack at the buzzwords :)

Jumping the Gun (2, Informative)

eldavojohn (898314) | more than 7 years ago | (#16750969)

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 [osflash.org] ):
The goal of the "Tamarin" project is to implement a high-performance, open source implementation of the ECMAScript 4th edition (ES4) language specification.
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 ... 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 (5, Informative)

Anonymous Coward | more than 7 years ago | (#16751109)

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

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 (0)

Anonymous Coward | more than 7 years ago | (#16751237)

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

Re:Jumping the Gun (3, Insightful)

99BottlesOfBeerInMyF (813746) | more than 7 years ago | (#16752173)

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 (1)

splict (1024037) | more than 7 years ago | (#16751231)

They are not offering flash but they are open sourcing the Verifier, JIT, core frameworks and the garbage collection engine http://www.kaourantin.net/2006/11/spidermonkeys-re lative-tamarin-joins.html [kaourantin.net] . The the newest Adobe ECMAScript VM is small and very fast and further along than Spider Monkey. This is very good for everyone involved, I believe, and a nice step by Adobe. Mozilla/Firefox users get a better ECMAScript engine and Adobe can concentrate more on the flash side of the flash engine. Read more at the FAQ on Tamarin http://www.mozilla.org/projects/tamarin/faq.html [mozilla.org]

Jumping the Javascript Gun (0)

Anonymous Coward | more than 7 years ago | (#16751301)

Excuse me but isn't Gecko an implimentation of ECMAScript aka Javascript?

Re:Jumping the Javascript Gun (1)

abdulla (523920) | more than 7 years ago | (#16751677)

Gecko is the rendering engine, it draws things. Spidermonkey is the javascript interpreter, it runs things.

Re:Jumping the Javascript Gun (1)

Anc (953115) | more than 7 years ago | (#16751731)

No, it isn't. Gecko is a rendering engine. The part of Mozilla platform responsible for JS interpreting is called Spidermonkey and it's quite a different component.

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 (2, Informative)

coyote4til7 (189857) | more than 7 years ago | (#16751527)

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 (1, Informative)

Anonymous Coward | more than 7 years ago | (#16751641)

The title read "Adobe and Mozilla Foundation Open Source Flash" when I read it before it went live. So essentially I jumped the gun when I wrote the post--which I entitled "Jumping the Gun."

Mod parent DOWN! (0)

Anonymous Coward | more than 7 years ago | (#16751575)

The parent is clearly FUD, someone please mod it down, not up!

Re:Jumping the Gun (1)

springMute (873579) | more than 7 years ago | (#16751595)

I find your theory pretty hard to follow.

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 (1)

ccr65 (767339) | more than 7 years ago | (#16751721)

As I understand it, this is the final step to deploying Javascript 2.0 which was sceduled to be included in Firefox 3 anyway, but since Macromedia/Adobe have been using it for awhile, this helps get the ball rolling faster and allows (as mentioned) better integration. This will also mean that XUL will have the same script engine as Flex. It's not just Web 2.0 however. Anything done in Javascript can use the new OOP language features. Microsoft has been using a form of ECMA 4 as well, but it's anybody's guess as to when IE will get it.

Jumping the Gun-Hole Javascript, Batman! (0)

Anonymous Coward | more than 7 years ago | (#16754025)

I'm wondering if this will close some of the Javascript holes that Mozilla has been having recently?

ECMAScript != Flash (1)

msobkow (48369) | more than 7 years ago | (#16751913)

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 (1)

Metaphorically (841874) | more than 7 years ago | (#16754451)

Um, that "vector/plane graphics animation technology" is called SVG [svgbasics.com] . VRML is a whole 'nother ball game. SVG is accessible from the DOM and thereby Javascript. SVG is already in Firefox and getting better with each release. By the time this new VM is available (2008 they predict), it's conceivable that the new VM combined with the SVG implementation that's in place by then could be another option comparable to Flash. Of course developers would probably also have to contend with deploying on whatever WinFX is by then too.

Re:Jumping the Gun (0)

Anonymous Coward | more than 7 years ago | (#16754561)

While you may know more than you put in the summary, I suspect you are jumping the gun here.

Gemal (the story submitter) is one of those people who tends to jump the gun - in the past, he's frequently announced "releases" of SeaMonkey and Firefox before they were ready, just as files start appearing on the staging FTP server or CVS files are tagged with a release tag.

If you need an ECMAScript parser.... (3, Informative)

tcopeland (32225) | more than 7 years ago | (#16751023)

...check out the Dojo project's JavaCC ECMAScript grammar [blogs.com] .

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.... (1, Interesting)

Anonymous Coward | more than 7 years ago | (#16751715)

The file you linked to is an an ECMAScript parser. It's the bytecode parser -- Abc stands for ActionScript bytecode. Its the intermediate format that Adobe's compiler creates and stuffs into .swf files for execution. The virtual machien parses the bytecode and executes the instructions found.

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.... (1)

mad.frog (525085) | more than 7 years ago | (#16752757)

Well, it *used* to stand for ActionscriptByteCode.

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.... (1)

tcopeland (32225) | more than 7 years ago | (#16753219)

> The file you linked to is an an ECMAScript parser.

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.

And evil hackers everywhere rejoice... (1)

0x537461746943 (781157) | more than 7 years ago | (#16751031)

tt the thought of yet another way to attack your web browser.

Re:And evil hackers everywhere rejoice... (3, Insightful)

starwed (735423) | more than 7 years ago | (#16751389)

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:And evil hackers everywhere rejoice... (1)

springMute (873579) | more than 7 years ago | (#16751707)

Technically, this won't change anything on any browser, just make JavaScript execution faster on Mozilla.

Please add multithreading (3, Insightful)

Anonymous Coward | more than 7 years ago | (#16751037)

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

Re:Please add multithreading (3, Interesting)

vaderhelmet (591186) | more than 7 years ago | (#16751101)

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 (2, Interesting)

twofidyKidd (615722) | more than 7 years ago | (#16752183)

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.

Re:Please add multithreading (1)

Anc (953115) | more than 7 years ago | (#16752363)

I don't really see the problem. If don't want multithreading then you just don't use it. Multithreading doesn't mean that every function you call returns immediately and is processed in in it's own thread. Now that would not only be silly - it would make the processing s language virtually unusable. You must specifically request the new thread to be created.

And btw, Mozilla's JavaScript implementation does support multiple threads.

Re:Please add multithreading (1)

BZ (40346) | more than 7 years ago | (#16752663)

JavaScript supports multiple threads quite nicely.

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 (0)

Anonymous Coward | more than 7 years ago | (#16753607)

There is no support for thread synchronization / mutual exclusion in the language. You can of course move the thread handling to the API, but that would be an ugly hack, not "supports multiple threads quite nicely". Besides, of course the point is that there is just one thread exposed to the web app. What good is threading if you can't use it?

Re:Please add multithreading (1)

mad.frog (525085) | more than 7 years ago | (#16752799)

Multithreading isn't on the table, but the ECMAScript 4 proposal (which will eventually be implemented in Tamarin) does include generators and iterators, which is a nice partial step to some easier coding techniques:

http://developer.mozilla.org/es4/proposals/iterato rs_and_generators.html [mozilla.org]

err (0)

JRWR (1001828) | more than 7 years ago | (#16751053)

guess i need to upgrade from my 200mhz p1 if im going to browse the web anymore

A Step in a direction (3, Informative)

vaderhelmet (591186) | more than 7 years ago | (#16751055)

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 [adobe.com] or Red5 [osflash.org] (OSS) My 7 cents.

Re:A Step in a direction (1)

foniksonik (573572) | more than 7 years ago | (#16751413)

Go here to see some really nice flash stuff: The FWA: Favourite Website Awards [thefwa.com] .

Re:A Step in a direction (1)

Ash-Fox (726320) | more than 7 years ago | (#16751943)

Doesn't work with tabbed browsing (middle click). Looked at a few website... Click something and it just keeps going into loading loops for a while. I have trouble reading some of the text on those sites and I simply can't do [ctrl] & [+] to increase the font sizes.
Not to mention I don't need to see distorted effects to display text on page.
I'm not particularly amazed by 360 views of people or objects, quicktime could do this long ago.
Nor am I particularly amazed by embedded movies in Flash either.
Somehow, some of the sites on there absolutely didn't work for me (using flash 9 beta). Such as "HOW EDISON ARE YOU?" or Adobe's own FWA showcase.

What the heck is it with sounds blurting out too? Don't I get a option to tell it not to play sound instead of it scaring the heck out of me with it's rumbling WHOOSH on my subwoofers?

This is poor webdesign in my opinion, you don't Flash for a entire page. Perhaps for specific elements like doing your 360 views, but the entire page and content? No.

Re:A Step in a direction (1)

foniksonik (573572) | more than 7 years ago | (#16752293)

You're missing out on the backend expertise here. The FWA itself is a database driven content managed site. Resize your browser and see how it adds rows and columns to fill up the available space (ie: it's a flash 'liquid layout' ) and the content is all being loaded on the fly asynchronously... JIT for you to view it. See at the top right of the grid how it paginates the listings dynamically according to how many columns and rows you have showing? Watch it while you resize again so more rows are showing... now start thinking of how that can be useful for other subjects. Dynamic data with realtime responses and monitoring of user input. Would it help if they used a large clunky interface to demonstrate this? Maybe a datagrid with words instead of funky pictures?

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 (1)

0racle (667029) | more than 7 years ago | (#16752969)

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.
Oh well that makes complete sense, I'll just stop listening to music I like because some jackass can't put a button on their site.

Re:A Step in a direction (1)

Ash-Fox (726320) | more than 7 years ago | (#16753221)

The FWA itself is a database driven content managed site.
In other words it's a flash interface to a CMS.
Resize your browser and see how it adds rows and columns to fill up the available space (ie: it's a flash 'liquid layout' )
Generally I'm browsing the web full-screen (F11). I was really annoyed at how the content wasn't already preloaded on the page, scrolling with the interface seemed very unnatural and slow loading because of this (not to mention my laptop fans were at maximum).
Resize your browser and see how it adds rows and columns to fill up the available space (ie: it's a flash 'liquid layout' ) and the content is all being loaded on the fly asynchronously
I still would of rathered a long page with thumbnails that dynamically changed positions (easy todo with basic HTML). Simply because I saw nothing wrong with it, and I still see nothing that innovative or new about this.
now start thinking of how that can be useful for other subjects.
Deviantart? I don't need Flash to make browsing that site unbareably slow and difficult to give out URL references to specific browsing thumbnails I'm looking at.
Dynamic data with realtime responses and monitoring of user input.
I don't consider Flash real time, if it's going to skip trying to show me a animation to display the animation, I also don't see how this is superior to AJAX, which works on far more platforms, browsers, doesn't break UI features.
Would it help if they used a large clunky interface to demonstrate this?
Seems like it's a clunky interface to me. Large? No, a bit too small to read.
Maybe a datagrid with words instead of funky pictures?
I'm opposed to Powerpoint presentations?
Anyways... did you go to http://www.flashearth.com/ [flashearth.com] ?
It's not as fluid/smooth as Google maps from what I can see -- just click dragging the area.
Also, Don't you know not to browse the web with your sound turned up?
I'm quite happy listening to music when I do things on my computer, not to mention I like to be notified when someone sends me a instant message/e-mail/says my name on IRC. I rarely ever browse flash based websites beyond Google video (lots of interesting speeches/demos are posted there).
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.
I don't own a TV, that issue you mention being one of the reasons.

It can't be any worse than SpiderMonkey (2, Interesting)

Anonymous Coward | more than 7 years ago | (#16751063)

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 (0)

Anonymous Coward | more than 7 years ago | (#16751147)

And this is related, how ?

Re:It can't be any worse than SpiderMonkey (1, Interesting)

Anonymous Coward | more than 7 years ago | (#16751313)

Because ActionScript IS JavaScript. Well, sort of - there are a number of extensions on top of it, but it's basically syntactic sugar. JavaScript and ActionScript use very similar backends.

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 (1)

wwahammy (765566) | more than 7 years ago | (#16751687)

To be fair though, while SpiderMonkey is slow, IE is just as bad.

Re:It can't be any worse than SpiderMonkey (4, Informative)

Rescate (688702) | more than 7 years ago | (#16751789)

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

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.

Linux distros required to include LOGO .. (1)

rs232 (849320) | more than 7 years ago | (#16752209)

"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

Re:It can't be any worse than SpiderMonkey (1)

BZ (40346) | more than 7 years ago | (#16752717)

> Almost all the problems people have with excessive CPU use are related to the JS engine.

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. (1)

SimHacker (180785) | more than 7 years ago | (#16755217)

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

cyfer2000 (548592) | more than 7 years ago | (#16753721)

I think the new stuff will become the "JIT" part for SpiderMonkey Mr. Brendan [wikipedia.org] has been talking for years, if not ten years.

Web 2.0... (1)

WarpSnotTheDark (997032) | more than 7 years ago | (#16751069)

Hmmmm. CMP Media is driving this thing...or O'Riley Media? I'm so confused.

Macrodobe (-1, Troll)

Konster (252488) | more than 7 years ago | (#16751071)

Macrodobe...making content suck...and suck HARD across browsers and platforms...we have no regard for your OS or browser! We will bend it over and make your starfish our own!

I for one do not welcome our Reach Arounding Uberlords. :(

Re:Macrodobe (-1, Flamebait)

Konster (252488) | more than 7 years ago | (#16751253)

That's Trollblait how? I suspect most of the mods here are French and use Debian.

There's a detailed commentary (4, Informative)

henni16 (586412) | more than 7 years ago | (#16751117)

..on the issue by Mozilla Foundation's executive director: Frank Hecker's blog [hecker.org]

JIT for javascript (3, Interesting)

augustm (147506) | more than 7 years ago | (#16751209)

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

Re:JIT for javascript (1)

JimRay (6620) | more than 7 years ago | (#16755213)

See, I just don't get this. I keep hearing "Yay! JIT for javascript" but my understanding of JIT is that it really works best for apps that are compiled down to bytecode (like Java applets and SWFs) first.

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?

So have I got this clear now? (1, Insightful)

Timesprout (579035) | more than 7 years ago | (#16751281)

When Adobe does Flash its shit, bloated, resource hogging intrusiveness. When Mozilla does Flash its empowering and innovative.

Re:So have I got this clear now? (2, Insightful)

starwed (735423) | more than 7 years ago | (#16751417)

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.

Re:So have I got this clear now? (0)

Anonymous Coward | more than 7 years ago | (#16751473)

It's not flash. It's JavaScript 2.0. JavaScript 1.7 is the current version in use in FF. In IE I believe it's 1.2. So until IE 8 comes out, you probably won't be able to use it anyways... assuming MS gets off their duff and fixes the back end.

Re:So have I got this clear now? (0)

Anonymous Coward | more than 7 years ago | (#16754675)

Sounds good to me...

When we hang Microsoft from the yard arm, we're going to loop Adobe right next to it. Outside of these two monopolistic thugs, damn near every other technology company is wearing a halo.

Read these before you spread FUD (4, Informative)

md17 (68506) | more than 7 years ago | (#16751295)

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

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 [kaourantin.net]

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 /. FUD away. ;)

Adobe needs to open the plugin's source... (1)

mi (197448) | more than 7 years ago | (#16751357)

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

Regarding Sig (0)

Anonymous Coward | more than 7 years ago | (#16751673)

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* )

Re:Adobe needs to open the plugin's source... (0)

Anonymous Coward | more than 7 years ago | (#16751779)

You may not know this, but the plugin does little work other than spawning off an instance of acroread (a separate process).

If that's true, then shouldn't it be rather easy to write a plugin from scratch?

Take it easy (5, Informative)

springMute (873579) | more than 7 years ago | (#16751431)

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

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.

Mod parent up! (1)

Anthracks (532185) | more than 7 years ago | (#16752063)

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 [mozillazine.org]
Frank Hecker's blog [hecker.org]

Request, Please. (1, Interesting)

LifesABeach (234436) | more than 7 years ago | (#16751503)

What are Mozilla's intentions now with respect to SVG [carto.net] ? One can not ignore that the specification of SVG [w3.org] with respect to Adobe's Flash [adobe.com] product. To my thinking, SVG [slashdot.org] , or its spawn, is the direction of future web developement.

Re:Request, Please. (1)

Metaphorically (841874) | more than 7 years ago | (#16754367)

Scripting is separate from the graphics. Maybe having a more closely related VM under the hood will make it easier for people to port applications from Flash to SVG on Mozilla though. I hope.

Re:Request, Please. (0)

Anonymous Coward | more than 7 years ago | (#16754643)

Please, please can someone answer this question? I am developing some javascripted SVG stuff at the moment, and very much want to know if I'm going in the dight direction by doing that. Currently, Firefox's performance is apalling when compared with Adobe's SVG plugin.

ECMAScript... (2, Interesting)

Bizzeh (851225) | more than 7 years ago | (#16752067)

...needs a less stupid name

Re:ECMAScript... (0)

Anonymous Coward | more than 7 years ago | (#16753073)

Oh, I know, I know!

ACME Script! (One Language to bind them all...)

Re:ECMAScript... (1)

Maian (887886) | more than 7 years ago | (#16753075)

Or you could simply just say JavaScript, since practically no one intends to code in pure ECMAScript (JS code just usually ends up being compatible with ES)... Okay, JavaScript's a stupid name too, but it's too late to change names now.

The beginning of the end of Firefox (0)

Anonymous Coward | more than 7 years ago | (#16753179)

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.

Actionscript 100 times slower than qbasic (1)

Dwedit (232252) | more than 7 years ago | (#16753291)

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?

Re:Actionscript 100 times slower than qbasic (1)

mjbkinx (800231) | more than 7 years ago | (#16753499)

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.

No 64 bit version (1)

obender (546976) | more than 7 years ago | (#16754855)

From Tinic's blog:

# If you study the source code you'll realize that a 64bit port is NOT a recompile away. We are actively working on the 64bit port, the source code right now is still 32bit until the changes required are stabilized.
Is this a gift to Mozilla or is it: please fix it for us?
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...