Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

Adobe and Mozilla Foundation Collaborate on ECMAScript 142

Posted by Zonk from the shiny-happy-pengins dept.
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."
This discussion has been archived. No new comments can be posted.

Adobe and Mozilla Foundation Collaborate on ECMAScript More

Adobe and Mozilla Foundation Collaborate on ECMAScript

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

    • Open Source Compiler (Score:3, Informative)

      by mjbkinx ( 800231 )
      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.

    • Re: (Score:1)

      by nickull ( 943338 )
      There are are lot of us within Adobe that haven't forgotten our roots and our first experiences with code often involved Open Source. Time to give back to the community. We also started RIA Forge and have some more open source projects on the go. www.riaforge.org. Tschuss! Duane Nickull
  • AJAX in Flash, with a Web 2.0 hype engine. May god have mercy on us all.

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

      by Anonymous Coward
      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 e

      • Re: (Score:2, Insightful)

        by strider44 ( 650833 )
        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: (Score:2, Informative)

        by mad.frog ( 525085 )
        Perhaps you should look at the code before calling it bloated.

      • Re: (Score:1, Offtopic)

        by Ant P. ( 974313 )
        I'd use Konqueror, but Firefox has certain things [kde.org] I can't live without.

      • Re: (Score:2, Insightful)

        by Maian ( 887886 )

        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]

      • 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...
      • 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 Spidermonke
      • I will disagree with your sentiment that both Adobe and Mozilla produce large bloated code bases. I think that given the stated requirements, both have done a good job. Nevertheless, if you don't like the code, at least now you can have a say and fix what you perceive is broken.
      • Adobe Acrobat 5 for me is still the fastest of all pdf readers in Linux, even if it has a relatively ugly motif interface look. As far as Windows goes, starting with Acrobat 6 things went very downhill in bloat, and my preferred version to use on Win2k is the last release official release for Win95, I think it's Acrobat 5.0.8. It's zippy, but it seldom complains of features not understood by this reader, upgrade, upgrade, upgrade, but it still displays things well anyway.
    • 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.
    • 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: (Score:2)

      by doom ( 14564 )
      ObsessiveMathsFreak wrote:
      AJAX in Flash, with a Web 2.0 hype engine. May god have mercy on us all.

      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)

    by eldavojohn ( 898314 ) *

    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 re

    • Re:Jumping the Gun (Score:5, Informative)

      by Anonymous Coward on Tuesday November 07, 2006 @09:40AM (#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: (Score:1)

      by splict ( 1024037 )
      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

    • Re: (Score:3, Informative)

      by coyote4til7 ( 189857 )
      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: (Score:1, Informative)

        by Anonymous Coward
        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."
    • 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 St

    • Re: (Score:1)

      by ccr65 ( 767339 )
      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 gue

    • 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 ev

      • 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

  • If you need an ECMAScript parser.... (Score:4, Informative)

    by tcopeland ( 32225 ) <tom@NoSPaM.thomasleecopeland.com> on Tuesday November 07, 2006 @09:32AM (#16751023) Homepage
    ...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: (Score:1, Interesting)

      by Anonymous Coward
      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, wr
      • 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...)
      • > 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.

    • 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 pos

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

  • Please add multithreading (Score:3, Insightful)

    by Anonymous Coward on Tuesday November 07, 2006 @09:33AM (#16751037)
    Javascripts single-threaded design is the biggest roadblock on the way to a web-app platform.

    • Re: (Score:3, Interesting)

      by vaderhelmet ( 591186 )
      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: (Score:3, Interesting)

        by twofidyKidd ( 615722 )
        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(arg

      • Re: (Score:1)

        by Anc ( 953115 )
        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: (Score:2)

      by BZ ( 40346 )
      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...
    • 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]

  • A Step in a direction (Score:3, Informative)

    by vaderhelmet ( 591186 ) <darthvaderhelmet ... inus threevowels> on Tuesday November 07, 2006 @09:35AM (#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.
    • Go here to see some really nice flash stuff: The FWA: Favourite Website Awards [thefwa.com].

      • Comment removed based on user account deletion
        • 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...

          • Re: (Score:2)

            by 0racle ( 667029 )
            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.
          • Comment removed based on user account deletion

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

    by Anonymous Coward
    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
    • To be fair though, while SpiderMonkey is slow, IE is just as bad.

    • Re:It can't be any worse than SpiderMonkey (Score:5, Informative)

      by Rescate ( 688702 ) on Tuesday November 07, 2006 @10:33AM (#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.
    • "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 SpiderM

    • Re: (Score:2)

      by BZ ( 40346 )
      > 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

      • 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

        • Re: (Score:2)

          by BZ ( 40346 )
          > Why as a matter of fact, yes, somebody HAS profiled SpiderMonkey.

          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 i
    • 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.
  • Hmmmm. CMP Media is driving this thing...or O'Riley Media? I'm so confused.

  • There's a detailed commentary (Score:5, Informative)

    by henni16 ( 586412 ) on Tuesday November 07, 2006 @09:40AM (#16751117)
    ..on the issue by Mozilla Foundation's executive director: Frank Hecker's blog [hecker.org]

  • JIT for javascript (Score:3, Interesting)

    by augustm ( 147506 ) on Tuesday November 07, 2006 @09:49AM (#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: (Score:2)

      by JimRay ( 6620 )
      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 transl

      • Re: (Score:2)

        by BZ ( 40346 )
        The current JavaScript engine in Gecko compiles the script to bytecode and then executes the bytecode... This is done during script parsing (not execution).
        • In fact, nearly every non-brain-dead scripting language does this (Perl, Python, Lisp, etc), with Ruby being one of the few exceptions. It's also one of the slowest, which is not a coincidence...
  • When Adobe does Flash its shit, bloated, resource hogging intrusiveness. When Mozilla does Flash its empowering and innovative.

    • Re: (Score:3, Insightful)

      by starwed ( 735423 )
      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.

  • Read these before you spread FUD (Score:5, Informative)

    by md17 ( 68506 ) * <james@james[ ]d.org ['war' in gap]> on Tuesday November 07, 2006 @09:57AM (#16751295) Homepage
    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. ;)

  • 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 Lin

  • Take it easy (Score:5, Informative)

    by springMute ( 873579 ) on Tuesday November 07, 2006 @10:05AM (#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.
    • 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]

    • Re: (Score:2)

      by jesser ( 77961 )
      This doesn't mean Mozilla will support ActionScript either, as it's just the virtual machine that's being opened, not the 'internal' functionality.

      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 ma

  • Request, Please. (Score:2, Interesting)

    by LifesABeach ( 234436 )
    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.
    • 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.
      • I think if SVG really flies, it would revolutionize the web, unfortunately SVG is too open and unpatented. What MS figured out with Suse and what Adobe might be after here, is that, at least in the US, ( unlike in the EU for now, but that's only a matter of time, money and effort), patents work well against open source, so if we can hijack the open source people to code for free to our patent, then we can still demand people using the code to pay up for our "technology", we just have other people doing the

  • ECMAScript... (Score:2, Interesting)

    by Bizzeh ( 851225 )
    ...needs a less stupid name

    • Re: (Score:1)

      by Maian ( 887886 )
      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.
  • 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: (Score:2)

      by mjbkinx ( 800231 )

      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 fo

  • The headline at inquirer reads "Adobe Hands Mozarella Foundation Flash Code"

    http://www.theinquirer.net/default.aspx?article=35 584 [theinquirer.net]
  • 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?
  • ...but when can I have it for IE6 and/or IE7?

  • GREAT news for OpenLaszlo, Firefox and AJAX! (Score:4, Informative)

    by SimHacker ( 180785 ) on Tuesday November 07, 2006 @03:08PM (#16756253) Homepage Journal

    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

    What is OpenLaszlo "Legals" [openlaszlo.org]?

    "Legals" is an OpenLaszlo project to provide a single application environment that supports multiple deployment runtimes. OpenLaszlo 3.x supports Flash 7 and 8 now, but Legals will extend that reach to include DHTML as well as Flash 9. And with the necessary infrastructure in place, we anticipate further runtimes will be developed by the OpenLaszlo community.

    The OpenLaszlo "Legals" project began at the start of 2006. We are projecting final availability by the end of the year. Developers interested in helping make Legals a reality are invited to contact us. Developers wishing to get a head-start building applications on top of Legals will be able to do so with our beta release in a few months.

    Many people ask about the back story for the project name. The name, Legals, is a tribute to a well-known local restaurant [legalseafoods.com] in Boston where a lunch meeting inspired the team to launch this project.

    See Legals FAQ [openlaszlo.org] for commonly asked questions and answers.

    The Architecture

    With Legals, the OpenLaszlo architecture is being remodularized into a true multi-runtime platform. OpenLaszlo generates script source that is compatible with ECMAScript Release 3, while leveraging extensions from ECMAScript Release 4. From there, multiple compiler backends generate JavaScript in the native dialect of the destination runtime: ActionScript 2 or 3, JScript 5.6, JavaScript 1.4+, and so on.

    The OpenLaszlo runtime library is being refactored into two parts: multiple kernels containing runtime-specific code, and a cross-runtime library written in standard ECMA-3. As part of the runtime library, the OpenLaszlo class system has been rewritten in ECMA-3 and includes several innovative new features.

    The OpenLaszlo runtime library delivers a common baseline of functionality across all supported runtimes. This gives the developer a rich environment in which to build full-featured web applications. In addition, Legals will include runtime-specific extensions so t

    • Re: (Score:2)

      by BZ ( 40346 )
      > An important feature currently missing from Firefox that I'm looking forward to is a way
      > 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/jsx drapi.h#45 [mozilla.org] for the API.

      Now you can't do it from inside the JavaScript language. But any consumer of the C JSAPI can do this.

      • 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

        • Re: (Score:2)

          by BZ ( 40346 )
          > Is there any reason it's not possible to allow web pages to download pre-compiled
          > 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.

Slashdot Top Deals

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Close