The V8 Myth: Why JavaScript is not a Worthy Competitor

Disclaimer: The following opinion is personal; it does not in any way reflect the opinion of Adobe.

UPDATE (01/18/2012): There have been some misunderstandings around the purpose of this post. The purpose is not to undermine JavaScript; it is to simply point out why ActionScript can do better given the compilation/execution model it inherently has.

UPDATE (01/18/2012): Some benchmark numbers posted below. More to come.

If you found yourself gaping in shocking disbelief at the premise in the title of this post, congratulations! You are the target audience for this post.

JavaScript programs are untyped, (relatively) small programs that are shipped/loaded as source code, and then compiled and run on the fly. In contrast, ActionScript programs are typed, (relatively) large programs that are compiled to byte code, shipped/loaded as byte code, and then run on the fly.

There is something inherently wrong in an argument that is based on the claim that JavaScript can do all its heavy-lifting work post-load time, and still do as good as, if not better than, a language that has the opportunity to do much of that heavy-lifting work pre-load time. What is wrong in such an argument is the reverence of, the dependence on, and the submission to, magic. Unfortunately, sooner or later, we all get to hear that Santa does not exist: the question is, can we grow up sooner?

Dynamic analysis is a great complement to static analysis: unfortunately, it is not a replacement. An ActionScript program that has been optimized to death by an AOT compiler can, almost trivially, beat a JavaScript program that is optimized on the fly by the JIT compiler. The only way out would be to let the JIT compiler work till death, but that is not an option! Checkmate.

So yes, you will hear about all the great things in V8 (JavaScript VM), including type inference. The fact is, there is no way a JIT compiler can afford to do the kind of modular analysis that an algorithm implemented in an AOT compiler can. To prove this unbelievably obnoxious claim, I compared the performance of the untyped JavaScript benchmarks in the Tamarin (ActionScript VM) performance suite, by passing them through, on the one hand, V8, and on the other hand, the type inference algorithm we recently prototyped in Falcon (ActionScript compiler), followed by Tamarin.

The ActionScript toolchain beat the JavaScript toolchain by around 3x.

(Note that a side-to-side comparison was never possible before we implemented type inference in Falcon; effectively, we regenerated the fully typed versions of the untyped JavaScript benchmarks automatically, and let the performance benefits enjoyed by typed ActionScript programs carry over to untyped ActionScript programs.)

So, let us stop worrying about JavaScript, and aim higher. As we focus on gaming, ActionScript programs will require significantly better optimizations for performance. ActionScript has just the right DNA mix for success, and it will become the 21st century language it could always be.

Sample numbers for Tamarin’s test/performance/jsbench benchmarks (running time in seconds for maximum datasizes in each case): 

  • SOR: 23.1 (V8), 4.6 (Falcon + type inference + AVM)
  • LUFact: 138.7 (V8),  23.3 (Falcon + type inference + AVM)
  • HeapSort: 10.0 (V8),  14.7 (Falcon + type inference + AVM)
  • FFT: 75.6 (V8),  31.1 (Falcon + type inference + AVM)
  • Crypt: 25.1 (V8),  7.4 (Falcon + type inference + AVM)


147 Responses to The V8 Myth: Why JavaScript is not a Worthy Competitor

  1. Dirk Eismann says:

    Hi Avik,

    thanks, this sounds very promising. Good to hear that you and your team are working on moving AS to the next level.

    Could you please provide more context in regards to the sentence “They will also require us to break away from legacy language features that have bogged us down, mostly borrowed from JavaScript”? Does that imply that future versions of the AVM won’t support these features as well (which leads to the next question concerning backwards compatibility)


    • Avik Chaudhuri says:

      Hi Dirk,
      Thanks for the kind words. We are working hard on ways to make AS run significantly faster in the future. In no way does that imply that AVM will not be backward compatible.


    • openisbetterthanfast says:

      I’ll use actionscript when you release the source.

      • Will says:

        The Taramin vm is open source.
        It is the base for running actionscript.
        Only the flash player API’s are closed source.

  2. Why not work with TC39 and add optional typing to ECMAScript (or rather, help with the efforts that are already underway [1])?


    • Avik Chaudhuri says:


      Thanks for the suggestion. I do not have any information on whether Adobe is going to retry after attempts to add optional typing to ES4 failed.


  3. Skarn says:

    Nice article, very interesting… but what about the “we believe HTML5 will be the best technology for enterprise application development” ?

  4. You’re 3 years late, just like Stage3D was. This is no longer anything to do with performance. It’s to do with money.

  5. Could you please provide the testcase you are benchmarking against?

  6. Hi Avik Chaudhuri,

    I am truely shocked and disappointed that you as “Programming Language Design Expert” @ Adobe (Please correct me if this is not you) have written this is post, you have provided no evidence to prove your points and therefore has no merit in it’s present form what so ever and is potentially highly inaccurate as it is simply your views on the matter without any performance data or examples to prove your point and.

    Secondly at least bugs in V8 get fixed, As a ActionScript 3.0 developer for 10 years the same bugs have been reported time and time again but never fixed I would suggest getting your own house in order first that complain about another piece of highly useful technology.

    So please provide the evidence that you use to state a 3 times speed increase for the ActionSctipt toolchain beating the JavaScript toolchain and what version of V8 where you comparing against? If you can’t then you need to write in bold this is simply your views and have no fact to backup your claims.

    Look forward to seeing the stats behind this post,


    • Avik Chaudhuri says:


      What I stated in post is fairly uncontroversial and unsurprising. I’ve posted some numbers which will hopefully do for now; I will post some more soon.


    • Alex says:

      James, you say you’ve been an AS3 developer for 10 years. AS3 has been around for 5 years. All Avik is saying is that given time, people are able to accomplish more than people who aren’t given time. If this seems unbelievable to you, give it a try some time. It’s not a slam on the V8 team – their constraints are set and they do an admirable job working within them. But when you remove the constraints, it’s silly not to believe that there will be ways to capitalize on the advantages.

  7. Mels says:

    Adobe finally strikes back, sort of

  8. Jan says:

    As an Adobe Certified Instructor in Flash I find this post revolting and very sad. Where are the numbers to back up your claims? I have been playing around with JavaScript for the biggest part of this year and I find it amazing what a scripting language can do compared to a compiled language like ActionScript. Nobody is “worrying” about javascript, instead people are broadening their horizons like every good programmer should do. How come I can make things in WebGL that run smoother in JS than the same thing in Molehill? I just about had it with all this hating and it’s post like this on an official Adobe blog that make me feel ashamed about my title as an ACI.

    • Avik Chaudhuri says:


      JavaScript has gotten better over the years, while ActionScript has been slower to react. I agree that there is nothing wrong with programmers “broadening their horizons”: competition is always healthy. However, it is frustrating to see the hype around JavaScript automatically translating into negativity around ActionScript: we are trying hard to wow programmers again, and we have been innovating again, and I am hopeful that we will be able to win back your trust.


      • Jan says:

        I understand that it is frustrating for you, but that is no reason to turn the negativity around and make a post like this without providing numbers to back up your case. When you write a post like this, you (and Adobe) do indeed come across as frustrated. I’ll have a look if I can find the said demo

    • Avik Chaudhuri says:

      By the way, it will be great if you can share the benchmarks that you found run smoother in WebGL than Molehill; I will pass them on to the graphics team.

  9. Unfortunately, this is a little too superficial.

    History shows that AOT optimizations can only go so far. Certainly, they can remove dynamic type checks and a number of dynamic dispatches. On the other hand, many inlining optimizations, or removal of dynamic tests, for instance, require either trivial dynamic analysis or impossibly complex static analysis. This is, in part, why JIT-ed Java beats hands down native code on some benchmarks (see the Big Language Shootout). This is, even, why native code JIT-ed to native code beats regular native code by a few percents (see Project Dynamo).

    Another factor playing against ActionScript is the sheer number of people actively working on making JS faster. These are smart people, with smart ideas, and they keep demonstrating that they can make JS quite fast. Fast enough to beat optimized native code in some of my personal benchmarks.

    I am not saying that AS cannot win. Just that static optimizations are not systematically better than dynamic optimizations.

    The game is on 🙂

    • Avik Chaudhuri says:


      The game is on, indeed. 🙂

      To clarify, we are not exclusively about AOT: in fact, we have mostly relied on the JIT until now, and will continue to work on improving it to match V8 quality. My point is that meanwhile, we also have the advantages of AOT we can exploit to go even further.

    • Christo says:

      Also the V8 team is basically the same team who built the hotspot jvm!

  10. Alan says:

    “That will be just fine; ActionScript has just the right DNA mix for success, and it will become the 21st century language it could always be.”

    Awesome! I can’t wait to see how well Flash performs in mobile browsers! It’s gonna smoke mobile browsers running Javascript!

    …oh wait….

  11. DQvsRA says:

    I always been interesting in question:
    “Does the ActionScript will be support a multithread capability in the future?”

  12. Evan Owen says:

    As someone who’s actually had to USE ActionScript (inside the Flash runtime) for a significant period of time in the past few years, I can tell you from personal experience that it’s one of the slowest, most inefficient environments I’ve EVER had to work with. The server-side Ruby code that backed it was faster at almost everything (especially manipulation of binary data), and that’s saying a lot.

    I now work with Javascript in the V8 engine on a daily basis, and in the real-world, and it very nearly hits the performance of statically typed, compiled languages. It’s so fast, we use it server-side as well, something we’d never even think of doing with ActionScript (mostly for unrelated reasons, but still).

    As they say, “lies, damn lies, and benchmarks”. Speaking of which, here are some actual numbers: Sorry Adobe, Flash (and ActionScript) is dead. Let it go.

    • Alex says:

      Well, here are some other “actual numbers” that show a somewhat different picture.

      Flash won’t die just because you’d like it to. Unfortunately, people have the unfortunate tendency to want to use the best tool for the job. In many cases that will be JS, but in others it will remain (or become) Flash. Saying that there is no point for the Adobe team to continue improving Flash is simply incorrect. If they make improvements, we’ll make use of them. Begging for a world with fewer options for yourself seems pretty silly.

    • Derp says:

      Server side code is one of the least performance sensitive coding you can do. Why do you think Ruby even got a shot at it?

  13. Ryan says:

    True words in todays compilers. 3x for your test perhaps. And google do go ahead with Dart… but it’s still pretty fast right 😉

    • Avik Chaudhuri says:


      Google’s move with Dart confirms the view that static types can make the life of language implementors (and of course, programmers) easier. The funny thing is, AS has had optional types for a long time. We can exploit that advantage better than we currently do.


  14. Arne Hormann says:

    You are certainly right – static typed languages do perform better. And JS has some legacy warts.

    But the advantages of javascript far surpass the speed argument.
    Javascript is supported by an enormous international community, sharing libraries and snippets for a variety of application scenarios. The pool of people knowing Javascript – and the available documentation – blow Actionscript right out of the water.
    The console and built-in interpreter present in most browsers porvide very immediate feedback during development. Accessibility and indexability are additional plus points.
    Javascript is coupled with every browsers, it provides tighter integration, automatic updates to the runtime and far better support for profiling and analysis of potential problems. The integration and distribution as source code instead of bytecode enables me to study other peoples code and improve my abilities.

    So please don’t get ahead of yourself, Javascript will stay.
    And if it will ever be replaced, I guess it won’t be by Actionscript.

    The only “advantage” beside speed that I see in Actionscript – and that’s not for the modern open web – is the obfuscation of sources. That’s about it, and it’s also the main reason I wouldn’t switch to AS.

  15. AS guy says:

    While I have personally witnessed the fact that ActionScript is tons faster usually, I have also witnessed the fact that a) Flash is unstable as hell on OS X b) Flash is unstable as hell on Linux c) Flash is (occasionally) unstable as hell on Windows…

    See where I’m going with this?

    I hate to admit it but JavaScript is looking a pretty good option when your Flash based app is used by people not on Windows who keep telling you it’s keeps making their computers unbearably slow or crashes their browsers…

    • JS says:

      Well-written Flash is stable on all platforms. We’ve had huge AS2 and AS3 apps running with massive concurrency on all platforms for several years, processing cash transactions in both business and gaming environments. There have been zero reports of browser crashes due to our Flash code.

      Badly written Actionscript, like badly written Javascript, can crash a browser. If your code is crashing browsers, it’s probably because you’ve made a mistake.

      • Chas says:

        nope I agree with AS guy, flash player is cr@p on mac as it is crashy, and a cpu hog, been that way for at least 8 years

        “There have been zero reports of browser crashes due to our Flash code.” 100% FLASE, I have sent Apple well over 400 crash reports of flash player crashing programs

        I have not seen flash player on Windows have much trouble, but I know from experience on many sites flash is very unstable, I have 70 times more stability with a pre alpha build of Opera (browser)

        I have even had flash player crash widgets on my mac

        • Alex says:

          You didn’t understand what he said. He (or she) is an application developer who has written Flash applications that don’t crash for his customers. The point is that the crashing most people encounter with the Flash player is not the result of the Flash player itself being faulty but rather people writing bad programs for it.

          Some people have written applications on OS X that have bugs that make them occasionally crash. Others have written programs with infinite loops that eat the CPU alive. Does this mean that we should say OS X is “crashy,” and a CPU hog? Obviously not. The Flash player is a platform, like OS X. Good and bad programs are written for it.

    • Kevin Newman says:

      Most of the best WebGL and higher end JS demos either won’t run at all (worse than a slideshow, a blank screen, or a compatibility message) or crash different browsers in different ways, or just look wrong most of the time, depending on the browser on my underpowered (normal dual core, 2 year old) equipment. Flash actually recovers better in most cases (except in Firefox on Mac), and runs smoother (fewer GC hiccups) when it’s pushed too far for this level of hardware.

      So no, I don’t see your point.

  16. Stefan says:

    So if I just get hardware 3x as powerful, I don’t have to use ActionScript? Cool.

    There was a time when Java could never, ever be a proper backend language due to speed issues, and servers weren’t written in JS. That just isn’t true anymore.

    If JS holds market share, and I believe it will, platforms and vendors will target it explicitly for performance improvements.

    …unless you’re arguing that the Half-Life 3 be written in ActionScript.

    • Avik Chaudhuri says:


      The 3x performance improvement is just an estimate on how ActionScript can already outperform JavaScript with source-level type inference. Obviously we will not stop there. There is a lot of low-hanging fruit to be had by optimizing the VM, to start with. This does not even include advantages that language improvements promise bring in.

      While JavaScript keeps improving, do not expect ActionScript to remain stagnant. And there is no reason why AAA games cannot be written in a (admittedly much advanced) future version of ActionScript. Languages keep evolving, and we are already seeing C++ ports of AAA games through Alchemy:


      • Jamal says:

        It’s funny that you should use Alchemy to hail the merits of actionscript, while the usage of these fast opcodes for Alchemy are supposed to become payed and there is no actual Actionscript support for them, as they can only be emitted by the Alchemy or opensource tools like Apparat, Haxe and the likes.

    • Avik Chaudhuri says:

      Also, I would encourage you to check this out:

      I don’t see why we cannot aspire for ActionScript to go in this direction.

  17. null says:

    how about native apps? does actionscript beats gcc? you say apples and oranges. i say apples and oranges for your javascript actionscript comparison.

  18. Pl4n3 says:

    Hmm, two points.

    – I doubt AOT is always better than JIT compiling. Sometimes during execution there might arise bottleneck slowdowns. A JIT compiler can then on the fly try optimizations, while the AOT compiler isnt running anymore 🙂

    – In a cluncky monolithic world AOT compiling might be the best option. In a dynamic environment like the web, where application parts or libraries might be loaded on the fly (yes as source, but maybe obfuscated, compressed = same size as bytecode) JIT compiling is simply the only way to go, AOT compiling doesnt work here.

    • Avik Chaudhuri says:

      Please read what I have written carefully: I never said that AOT is always better than JIT. I am simply against the view that JIT alone can always outperform AOT. I am all for a hybrid approach (re: “Dynamic analysis is a great complement to static analysis: unfortunately, it is not a replacement.”)

  19. Kudos on hinting that Javascript developers have to grow up 😀 a great start for the inflammatory comments that are sure to follow.

  20. Byte code is still interpreted code no? Anyway, flash is a dying platform and therefore so is ActionScript?

  21. t says:

    tere is no actionscript on mobile.

    • Avik Chaudhuri says:

      You are wrong. There is certainly ActionScript on mobile, not on the browser but as apps!

  22. This is some pretty tough talk with only hypothetical numbers to back it up. It would be a lot more compelling if you showed the actual benchmark results. Alluding to them like this without even describing what was benchmarked makes it seem highly suspicious that you hand-picked a benchmark where ActionScript happens to beat JavaScript. In our own benchmarks [], V8 does amazingly well, coming close to C performance on many tasks. The main drawback for our purposes is actually JavaScripts inability to easily link to and use standard C/Fortran libraries.

    • Avik Chaudhuri says:

      I don’t understand your argument. Don’t you agree that whatever V8 can do, we could also do in principle, and more? Certainly we are going to try improving our JIT numbers. But meanwhile, we can do several optimizations at static compile time. Also, check out Alchemy

  23. The reason you give for it not being a competitor is precisely the reason that it is. Javascript doesn’t need an AOT compiler, it’s natively supported in every browser. People are doing amazing things with Javascript and HTML5. It may not be as optimized as an ActionScript application, but that does not matter in most cases. The benefit is not needing Adobe, or any other third party plug-in.

    • Alex says:

      And the drawback is living within the confines of whatever all of the major browser companies can agree on to implement and when they decide to get around to it. Flash is a tool – nothing more than another option for developers. Years ago browser developers added plugin functionality to their browsers because they recognized that by allowing individuals and individual companies to innovate, they could help the web grow faster. I don’t want to return to a world where the only people who are allowed to improve the web are those who are employed by Microsoft, Google, Mozilla or Apple.

      Plugins allow for a freer, more quickly evolving web. We’re always better off if we’re free to decide which technologies should exist based on their merit rather than some artificially imposed set of rules restricting what technologies are allowed for consideration.

  24. Joe S says:

    I typically prefer bar charts with any claim of speed increases that can’t be verified.

  25. Awesome says:

    That’s super exciting, now if only I didn’t have to depend on flash on the client. Maybe server side flash is a possibility. I cringe, I smile, I weep, I’m overjoyed.

  26. imjoshdean says:

    Can we get some data to back up the claim that ActionScript’s toolchain beat JavaScript’s by ~3x?

    I’m not going to call you a liar, but the proof is in the pudding.

  27. Tim Branyen says:

    A number of things I’d like to comment on here… but I think it would be best to start with you backing up a number of claims in your post.

    “An ActionScript program that has been optimized to death by an AOT compiler can, almost trivially, beat a JavaScript program that is optimized on the fly by the JIT compiler.”

    “To prove this unbelievably obnoxious claim, I compared the performance of the untyped JavaScript benchmarks in the Tamarin (ActionScript VM) performance suite, by passing them through, on the one hand, V8, and on the other hand, the type inference algorithm we recently prototyped in Falcon (ActionScript compiler), followed by Tamarin.”

    “The ActionScript toolchain beat the JavaScript toolchain by around 3x.”

    ” As we focus on gaming, ActionScript programs will require significantly better optimizations for performance.”

    “ActionScript has just the right DNA mix for success, and it will become the 21st century language it could always be.”

    I think once some of these claims are backed up, it’d be great to continue the conversation…

    • Avik Chaudhuri says:

      I will only take on the last point. ActionScript has a mix of static and dynamic typing that is very well-suited for writing games: write the game logic in a high-level scripting language, and all the performance-sensitive number crunching in statically typed code. We are working on further language features that routinely appear in modern languages and that will make the suitability even more obvious.

  28. Scott Kurland says:

    So you don’t know why a programmer might want access to the source code, don’t understand dynamic typing, and weigh your programs by the line to figure out how valuable they are.

    • Avik Chaudhuri says:

      Of course dynamic typing has its benefits: but clearly it cannot replace static typing, which is why a hybrid approach (as in ActionScript) strikes the ideal compromise.

  29. OldMan says:

    Shock! Horror!

    Compiled language found to be faster than interpreted+JIT language!

  30. Jeff Dickey says:

    Do you have an argument aside from dynamic compilation? Can you say ActionScript has any advantages other than strictly performance?

    I write a lot of JavaScript code, and I personally never hit performance struggles with it. More often my CSS is susceptible to performance drawbacks. Although, to be fair, I’m not making games with it either.

    • Avik Chaudhuri says:

      Well, yes. Classes in ActionScript allow a much cleaner object model (method lookup becomes easier, for instance), which is why we saw a 10x performance improvement when we moved from AS2 to AS3.

  31. J says:

    When ActionScript is an open, standard platform I’ll consider it. I can’t picture myself voluntarily submitting to work under Adobe’s cloud. In other words, I have no particular issue with ActionScript as technology, but in my IT experience, Adobe has been so difficult to work with that I would never stick with them when there is a perfectly good alternative.

  32. S. Jones says:

    I agree that ActionScript is flat-out superior to JavaScript both technically and performance-wise. But, history will favor JavaScript for too many reasons to count: It is widespread, flexible, has low barrier to entry and is the common language of web and mobile apps.

    Rather than hoarding ActionScript’s superior DNA, Adobe should be working very hard to bring strong typing and pre-compiling to JavaScript standards. With Adobe’s influence and expertise, It could easily be the next evolution of JavaScript but the window of opportunity is short: Moore’s Law will make static analysis irrelevant as dual-core mobile processors make my Angry Birds fly just fine using creaky, old post-load optimized JavaScript.

    On the other hand, if Adobe brought its gifts to the JavaScript camp, a cleaner more turbocharged JavaScript would be a Trojan horse that even Apple couldn’t refuse. Everyone would win and Adobe would be at the center of it.

  33. While your benchmark is certainly valid, your general argument is weak and you come to a mistaken conclusion.

    Your argument assumes that compiling a program is a fixed amount of work, hence a AOT compiler will always have an advantage.

    This is wrong.

    We can chose how much effort a compiler expends, and this choice has a complex relationship with the execution speed of our built program. Read Andreas Gal’s PhD thesis, then look through the source of LuaJIT for an example of how one can achieve peak execution speed while spending only a fraction of the time that’s typical inside the compilation machinery.

    What this means is that AOT vs JIT vs Tracing is a complex topic with no simple winner. Real systems will increasingly be hybrids.

    Lastly, wtf does Santa have to do with anything? If you’re making a claim, support it with a logical argument and evidence, not a lame rhetorical appeal.

    • Avik Chaudhuri says:


      if you read my post carefully, you will realize that I am not arguing that AOT is better than JIT: I am arguing that JIT alone is not better than AOT. I agree that hybrids are the future. Currently, ActionScript relies a lot on the JIT, and not so much on AOT: I’m sure that as we move more and more optimizations to the AOT, we will see better results.


  34. Bradley Meck says:

    Do you have the source for the benchmark and results? Would be interesting to see them.

    Either way, the toolchain of adobe flex vs. easy to embed / use environments like Node or the V8 C++ API are the big problem that a lot of places have when trying to things outside of web pages. The lack of typing does cause some initial performance loss, but dynamic analysis is not the only concern as untyped values coming across a bridge will not have a good performance either way (AOT or JIT). Analysis of types at runtime, snapshots of compiled code, and ahead of time analysis (it can and has been done on Javascript but it is non-trivial and will not be used if only JS source is provided) all need to be combined together. There is no silver bullet on either side.

    • Avik Chaudhuri says:


      Thanks for the well-rounded comment. Agreed that a combination of all these is the key: my point is that a lot of type-based analysis can be easily done as ahead-of-time analysis. Dynamic analysis is better suited to discovering deeper invariants about the program than types. In short, if the invariant is path-sensitive, dynamic analysis can trump static analysis; for something that is path-insensitive, such as types, static analysis is usually better, especially for usual, non-metaprogramming-style code.

  35. Julien Castelain says:

    This post just states the obvious. I think the hype about JS node and all that is because it allows users to finally access features that weren’t available before without installing a plugin and it’s great. Having been a Flash platform fanboy for years, it seems like Flash’s place is now the desktop and games… Don’t blame people for not wanting to use it anymore so you can’t really compare AS3 and V8 … Oh and if you want we can compare AS3 ‘s performance vs C++. I think frustrated AS3 devs should open there minds before reacting like this, if you don’t like the web, stay in your VM we won’t complain

  36. Linuxuser says:

    I use Linux. Here, V8 is faster than the Flash Plugin.

  37. Everything you said us true. However the web works best when we use open standards. Open it up and I’ll take you more seriously.

    It would be easier to add type checking to JavaScript than to change the world to use ActionScript. There is at least 1 proposal for adding type checking.

    Lastly, this is an invalid comparison. You can’t add a few lines of AS in a form to validate input. You can’t use AS without it being the web page.


  38. Raynos says:

    And that kids is why ActionScript is FOUR TIMES SLOWER then javascript ( )

  39. Neil says:

    These are all very strong points, however JS simply has more traction.

    Furthermore, client-side performance will never be as important as IO latency on the web.

    As a tool for the front-end of the web, i would argue that development simplicity and platform agnosticism are more important than client-side performance.

    Great article!

  40. Rene Dudfield says:


    Well, allow me to retort.

    AOT compilers exist for dynamic languages (see shedskin for python, and hiphop for php as two examples). Also, trace hints can be cached – much like profile guided optimizations. JavaScript implementations could theoretically use these two ways of AOT for commonly loaded JavaScript.

    Another area where JS can improve is through its interpreter. Luajit2 shows that an efficient interpreter has a great effect on many benchmarks. Especially run once code, where JIT completely fails.

    Gaming makes use of the GPU, which can be programed with dynamic languages nicely too. Dynamic languages like python can automatically use the GPU or multiple cores for numeric processing – something which JavaScript could also do theoretically. GPU and multicore use in games can easily turn into 50-100x speedups for some algorithms.

    The real issue that both JavaScript and ActionScript have with gaming is latency. A pauseless GC is theoretically possible with both though, as is more deterministic memory management.

    That is evidence that JavaScript has heaps of room left for optimization – before it needs to turn to static types.

    • Avik Chaudhuri says:

      Hi Rene,

      Thanks for the excellent points you make. You are basically stating that JS can improve a lot, and I am making the point that AS can improve a lot, too, and even more. In particular, I can assure you that we are looking at all of the areas you mention as well (more AOT optimizations, GPU utilization, better GC)!

  41. Thaddee Tyl says:

    I would be greatly interested to having a link to a git repo of your benchmarks.

  42. Enrique García says:

    First of all, where are those test suites?

    Second, you seem to be comparing the “stock” V8 with a not-yet-release prototype. I don’t think that’s fair – the V8 engineers should also get the chance of using their most beta-but-faster software, too.

    Third, I can browse the source code of v8 and check what it does myself. Or pay someone to do it for me. With AS, I just have to take your word for what it does.

    Finally, well, if 3x was the best it could do, I’m frankly not impressed.

    • Avik Chaudhuri says:


      I am using the release version of Tamarin for my experiments, too. It is the type inference part that is a prototype.

      3x is certainly not the end: it is what we can have today. Meanwhile, we are working on all parts of the language and the VM to find ways of improving performance. I will share more experiments in a later post, but for now, yes, you have to take my word for it. (But if you looked closely at the language and the VM, you will find that there is a lot of low-hanging fruit, so you should not be surprised.)

  43. jell says:

    if You are speaking something about jit, You should read something about
    v8 isn’t so good as a jit implementation, it’s optimized only for short time runners.
    for long runners tracing jit is much better solution.

  44. lordB8r says:

    Wowzers…Thanks for sharing!

  45. Thanks for the info, I’ve been interested in this for quite some time,i totally agree with your opinion

  46. FFT, crypt and LUFact are things that long should be optimized using native code, in JavaScript and in AS as both are really important language constructs.

    • Avik Chaudhuri says:

      Overall, I agree that more (primitive) standard libraries are required for both languages. However, at some point you need to stop and let the languages grow on their own.

  47. Jeremy says:

    Java programs are strongly typed, relatively large programs that are shipped as byte code. The JVM is also mature and performs quite well. Can ActionScript top it?

    And, if you hate Java, you can write your code in a number of other languages that run on the same VM.

    So what killed Java?

    • Avik Chaudhuri says:

      ActionScript has many more language-level constraints than Java, but in principle, yes, with enough freedom and enough work I don’t see any reason why we cannot top Java.

      There is also no reason why we cannot do better in certain areas. Certainly generics in Java is not a glaring success.

  48. kripken says:

    1. The JS JIT can most definitely be run “to death” as you say, if it optimizes in the background. IE does this already. For long-running code (like games), there is therefore no reason it cannot match AOT compilation, since it can do exactly the same things. I do concede though that AOT will win on initial startup.

    2. SpiderMonkey TI has better type inference than V8, so it might run these benchmarks better potentially (assuming they are gated on type inference). So I’d be curious to see the results on SpiderMonkey trunk as well.

  49. Jeff says:

    Did you run the closure compiler with advanced optimizations (and jsdoc type annotations)? You can get huge improvements this way, and any real depoyment uses it.

  50. Hi Avik,

    I did some digging into V8 perf on these benchmarks:

    tl;dr version: SOR&LUFact are much faster when you use Float64Array instead of Array (to save V8 from boxing doubles) [factors of 6 and 10], FFT hits some bug in V8 which should be fixed (and will also benefit from Float64Array I presume), Crypt is hard but also can be improved by a factor of 6 if I massage the code to make it more optimizer friendly.

    • Avik Chaudhuri says:


      What you are saying is that either the benchmarks or V8 can be tweaked to get better performance out of V8. Do you think that is fair? (Personally, I am not against trying it out, but then you can make the same argument for ActionScript, too.)

      • I think using typed arrays is fair because they are becoming part of the web (even IE 10 supports them to a certain degree). V8 also tries to unbox double arrays automatically, but these heuristics are not fully tweaked yet and do not always kick in. I personally think that programmer should be ready to give VM hints and should not expect VM to always automatically guess the best representation for his data structures.

        However the change I did to Crypt was much more drastic (using typed arrays was only a very small part of it). I am not sure how to estimate it’s “fairness”. Original Crypto really reveals the fact that V8 does not “introduce” uint32 representation in optimized frames, only double and int32 representations. On the other hand it might be interesting to see how AVM performs if multiplication mod 0x10001 is rewritten in a different way.

      • regarding tweaking V8 part: it’s not about tweaking for a particular benchmark, it’s about fixing an obvious bug (in case of FFT).

    • kripken says:

      Thanks Vyacheslav for this analysis. Reading the longer version, it seems that basically ActionScript has done better than V8 here only because of (1) specific limitations of V8 (boxing of doubles), which are actually pretty easy to avoid (using typed arrays), and (2) in one case, a specific bug in V8.

      This is exactly why it would be very informative to compare ActionScript to several JS engines. The limitation of boxing doubles doesn’t exist in Firefox or Safari, for example (they NaNbox), and the specific bug in V8 would not have been hit either. Of course, those JS engines have their own limitations and bugs, but the point is that if you compare ActionScript to JS, don’t compare it to V8: JS is not one engine but *several* excellent engines. I strongly suspect if you benchmark a few other engines here (as other said, preferably the dev versions), you would see very different overall results.

      • I would not say boxing is a limitation. It’s a design decision. SM/JSC choose differently.

        And yes, comparing to other engines might be insightful.

        • kripken says:

          Yes, sorry for phrasing that as a limitation. It’s a design decision, with some advantages and some limitations, of course.

          My point was that in the benchmark here, it happened to run into some of the disadvantages of that design decision, and since just one JS engine was benchmarked here, the results reported could be misleading.

  51. Andrew says:

    My team maintains a JS and an ActionScript codebase for our Flash & HTML5 charting library (, and has done extensive performance testing in various rendering scenarios. There is no clear winner for all scenarios, but for the more complex renderings (i.e. charts with many thousands of points), the Flash render wins out consistently.

  52. geddesign says:

    I used to be a huge fan of ActionScript (and Flex). Several years ago it was the best game in town for building rich UIs in the browser. That’s simply no longer the case. And the death of mobile flash is the nail in the coffin. Why would I want to build something that only works on desktop browsers? It’s clear why ActionScript is focusing on games: that’s the only remaining niche where HTML5/JavaScript don’t beat ActionScript. That too will change (with WebGL especially) and then you’ll have to think twice about telling people ridiculous things like not to “worry” (lol) about JavaScript, and Santa doesn’t exist.

  53. I wrote a bit of an explanation of my interpretation of what you were saying and implying in your post, with the target being a particular community of ActionScript developers. I thought you might be interested in reading it, and that some of my explanations might help your readers here understand parts of your post that I personally had trouble with the first time I read your post.

    Here’s the body of the post:

    As I understand it, he is saying that Falcon (a new version of the AS compiler) will finally include many of the compile-time optimizations that people have been asking for since 2006. Especially, there are a lot of silly, type-related conversions and checks/guards that appear in the bytecode for type annotated ActionScript code, even though you’d expect that they could be enforced statically. Indeed, Avik [URL=””]says[/URL] that they are working on it: “(3) optimizing code by eliminating dynamic checks wherever they are subsumed by static checks.”

    Quote from Avik Chaudhuri:
    The funny thing is, AS has had optional types for a long time. We can exploit that advantage better than we currently do.


    There is a lot of low-hanging fruit to be had by optimizing the VM, to start with. This does not even include advantages that language improvements promise bring in.


    ActionScript has a mix of static and dynamic typing that is very well-suited for writing games: write the game logic in a high-level scripting language, and all the performance-sensitive number crunching in statically typed code. We are working on further language features that routinely appear in modern languages and that will make the suitability even more obvious.

    The remarks he made on the speed comparisons he makes between JavaScript and AS3 were a little hard for me to decipher at first, due to the way they’re running benchmarks that originated in JS, and because it’s not immediately clear whether the results are comparing JS to the current version of the ActionScript compiler or a future one.

    After reading through the post and the comments a few times, it seems that he’s using Falcon and the public / release version of AVM2 that’s in Flash Player today. This is an important distinction, because there are two separate things being improved upon in the version of AS / the compiler he’s using: 1) type-inference and 2) Falcon’s optimizations.

    The type inference portion by itself is essentially taking untyped ActionScript and inferring types to use during compilation (for optimization). For example, it could probably tell you that (var s = ‘hi’) was a string (and do the same for more complicated code).

    The part that I found a little misleading without reading closely is that ActionScript _with_ type annotations [i]today[/i] is still often slower than JavaScript. This caused some outrage in the comments and from JS+Mozilla people, since, as senocular (and Adobe employee) will tell you, “JS is faster. We know it.” I don’t think Avik intended to be misleading; he may have just been so familiar with his own work that he didn’t phrase it properly.

    So, while the type inference portion effectively annotates existing AS, you still need the Falcon improvements to see the performance benefits that are being touted in the post. It also means that you may not need to write your own annotations in ActionScript all the time to see those future performance benefits, but you’ll probably have to recompile your code.

    Quote from Avik Chaudhuri:
    While JavaScript keeps improving, do not expect ActionScript to remain stagnant. And there is no reason why AAA games cannot be written in a (admittedly much advanced) future version of ActionScript. Languages keep evolving, and we are already seeing C++ ports of AAA games through Alchemy

    So it sounds like language changes are pretty certain, and it also sounds like they are almost entirely focused on games (and preserving backwards compatibility) rather than Flash’s traditional multimedia or web application uses. That last part shouldn’t be too surprising given recent events, but it is weird in the context of comparing JS to AS, since people are still focusing on making web apps and multimedia stuff in JS.


    One thing that initially bugged me about the article was his use of the term “AOT” (ahead of time) when talking about compilation. The common definition of an AOT compiler, is something like this:

    Quote from Wikipedia:
    “””An ahead-of-time (AOT) compiler is a compiler that implements ahead-of-time compilation. This refers to the act of compiling an intermediate language, such as [ActionScript bytecode], into a system-dependent binary.

    This is _not_ what Avik is talking about in his post. There is in fact an AOT compiler for ActionScript bytecode, which is used to compile ActionScript to native code for mobile platforms like iOS. Again, that is not what he is talking about. He’s using AOT as a more general term describing code analysis and optimization that occurs in the ActionScript compiler _before_ it is turned into bytecode.

    I think his use of the term that way is fair, but it is not what people usually mean when they talk about AOT. AOT was introduced as a term to distinguish between JIT compiled code and code that compiles to bytecode, but that is compiled to machine code before the code is distributed to different platforms. It’s much like traditional compilation except that there is typically some architectural reason for having the intermediate bytecode step; in the case of Flash Player it’s because SWFs that target the web _need_ to be in platform-independent bytecode to run on multiple CPU architectures, but that’s not the case on iOS AIR apps because you know that you need ARM instructions, and bytecode interpreters are very often not allowed in approved iOS apps.

    So, he’s only talking about AOT in the sense that the optimizations happen at compile time instead of at runtime (like JIT). They would occur before the “AOT compilation” step. It may seem like a trivial detail, but imagine being in my shoes as I read the article for the first time and wondered why he was comparing the performance of platform dependent code to JavaScript.

    (originally posted here: )

    That was my post, I hope it helps, and I’d love to hear your thoughts on it as well.

    I’ll be at POPL next week and will certainly attend the “The Ins and Outs of Gradual Type Inference” talk. 🙂

    • Avik Chaudhuri says:

      Thanks for the post, Kyle.

      One major clarification: the version of Falcon I’m using does not yet have any optimizations: it more or less mimics the byte codes generated by ASC (the existing compiler). So the perf. improvements reported are solely due to inferred type annotations.

  54. Brian Lesser says:

    You mention that you prototyped the type inference algorithm in Falcon. Is that the same compiler Adobe is donating to Apache Flex and will the donated compiler include the the type inference algorithm? After Adobe donates Falcom to apache Flex will AOT optimization on the open-source compiler continue?

    • Avik Chaudhuri says:

      Hi Brian,
      I am not in a position to know or discuss Adobe’s strategy around Falcon. Hope you understand.


  55. Xucrutao says:

    Ok, I undestood. I’m not an actionscript nor javascript developer. I understood all u said, but, so what?! Whats the solution? Flash??? No it’s not, its barely runs on my linux machine 64 bits, its just run on mobile as an app and it’s will never be a default cause its not a free technology. The world of developers already took a position and its not actionscript, at all. So stop complaning about the technology u guys developed and start accepting that its not what the developers wanna. Now swallow ur tears and start writing about something that worth be written.

  56. st33d says:

    I’ve been a Flash developer for many years and all I can say is this:!/FlashHasCrashed

    I like AS3, but I really, really hate the toolchain.

    Is Adobe going to fix it?

    If they do they’ll probably charge me a lot of money simply to use something that works instead of supporting the exorbitantly priced product we already bought.

  57. Raynos says:

    > The ActionScript toolchain beat the JavaScript toolchain by around 3x.

    That would make ActionScript about 10% faster then C. Congratulations, quite an achievement.

  58. Geoff Wagner says:

    All of your arguments are good, except every time i load a website with flash, my CPU spikes, my fans kick on high gear, and i can barely use any other application (because of the bulky, poorly written, unoptimized goliath that is the Flash VM) vs a site with JS, like, that runs very smoothly and doesn’t cause my system to try and implode on itself. You may be right that you benchmark faster than V8, but benchmarks dont mean anything when your product should have died years ago because of how poorly designed and poorly implemented your one thing to everybody technology is. Stick to PDFs and Photoshop and leave the web stuff to people who are open and support the growth of technology.

    • Avik Chaudhuri says:

      I have no argument against the code quality of the existing Flash/VM. But I can assure you that a lot of extremely talented people have come together and are trying to fix that today at Adobe. We have had a lot of constraints, and we have been trying to relax some of them. But we are on the path to huge improvements. It will take some time, but not too long: and since you believe my arguments, you will know that any kind of momentum will keep multiplying our progress and the advantages we inherently have.

      • Geoff Wagner says:

        The only advantage to flash is the cross browser compatibility. HTML5 / JS has that baked in and is supported by an open source, and much larger community than the developers on the flash team. It is the Apple VS Android debate. Android has a much larger following and community, and people are bound to gravitate that way (and they are) but apple has this elusive cult following. The huge difference in this case is, adobe puts out a product that freezes up your computer, while the competitor puts out something that has a nice polish that doesn’t need a cult following or any extra plugins to install.

        A similar argument can be made about Facebook groups vs G+ circles. Facebook does a great job of pre-grouping a lot of your friends for you, while G+ makes you do all the work to group your contacts. Adobe makes you jump through their flash hoops by installing plugins while HTML5 / JS is just there, and works well.

        I have no doubt at the talent of the adobe flash team, i just wish they wouldn’t waste their time on an antique piece of technology, and would further the development of the STANDARD!!

  59. Isn’t the comparison similar to comparing the speed of any given JS application and any given OS-native application?

    If you must discuss only speed, where is the bar? What if both environments have passed the necessary speed threshold? Dragsters are faster than Bentley’s, but who wants to drive a dragster to work?

    It would seem to me more relevant to look at factors that aren’t about raw speed.

    Markets aren’t usually won on one factor. Old advertising used to talk about quality, and strength, and workmanship (our natural leather boots are hand-crafted by generations of artisans). New advertising sells to a market (Just do it). It’s not so different here. Would Facebook be better if built in Flash? Easier to maintain? Expose to developers? Would it have gained more users? Made more money? Puzzle over that for a while.

    Besides, the speed game is tricky. There is a neckbeard reading this, maybe taking a break from building his new supercomputer language, who has just spilled coffee on his shirt (from all the laughing, you see).

  60. Phillip Kerman says:

    Not sure what I can add here. My take: lets say you’re totally correct (which, really, the claim a compiled language having some advantage over JIT seems easy to swallow)… it’s moot. There’s a much more active groundswell of activity behind JS. Plus, I’ll do whatever clients want. If they say they want something to work in specific platforms I’ll be the last one to try to talk them out of it. Making a case for performance would a) have to be provable and b) have to be significant. Right now I do think I can do many jobs faster/cheaper using AS3.0 but that is slowly changing. (I do think some businesses are misguided and they spend money in development when simply using Flash could save them money… but it’s still moot).

    So, again, I’ll just accept the performance argument. But when you mention “low-hanging fruit” it makes me cringe. Why wasn’t this addressed years and years ago? And, maybe I’m just jaded, but when I hear adobe talk about what’s coming… and it takes years to appear.. I begin to stop listening. Not that I’m not interested or on board when it arrives, but my clients need stuff now. NO ONE (that I work with) plans for what technology is supposed to be coming–and from a company which, frankly, has been pretty freakin’ flaky lately!)

    Finally, what in the world am I to make of that disclaimer? Seriously, that just confuses things. I honestly don’t know what that means.


  61. Mahron says:

    And how long will we have to wait for this 3x+ boost ? 1 year ? 2 ?

  62. Paul Roberts says:

    Flash is a slow piece of junk, and anyone who thinks otherwise is fooling themselves. Pull up any flash site on the fastest phone you can find, and watch the thing slow to a crawl. Hell, watch some youtube videos on a Core 2 Duo, and just listen as the fans ramp up to cool down the cpu as it strains to render some crappy low res video.

    As someone who’s written flex applications for the past 3 years, I can tell you how glorious it feels when I’m asked to replace a flex app with a javascript one. Our old flex pages were so bloated and disgusting, they would take 8 seconds to load, even while on our corporate intranet. Oh, and all of our flex applications would mysteriously crash the flash plugin if you left it open for about an hour. We weren’t doing anything weird in our apps, and it was actually multiple different apps all exhibiting this same behavior (which an entire team spent 4 weeks trying to troubleshoot to no avail).

    And even if flex performed as well as we’d hoped, there was still this ridiculous notion that we had to wait so long for everything to compile. Our entire java backend that drives the flex apps can be built in 2 minutes, but to compile just one of our flex applications takes 3 minutes. What’s wrong with this picture? It takes me 3 minutes to make one tiny styling change and see the difference? In javascript land, we can make any change we want and see the results instantaneously.

    Dumping flex for javascript was the best thing my company has ever done, and that is the consensus among the 50 developers who work there.

    • Avik Chaudhuri says:

      I don’t see what your argument is. This post is trying to tell you that we are going to make ActionScript run much faster than what it is currently. Furthermore, the whole point of writing the new compiler, Falcon, is to significantly speed up the compile times you are complaining about (taking advantage of concurrency, to begin with). Bottom line, your complaints are valid and we are going to address them in definitive ways very soon. Meanwhile, JavaScript is ahead. It is not going to be for very long.

      • Paul Roberts says:

        If this article was intended to “tell you that we are going to make ActionScript run much faster than what it is currently”, then it needs to be completely re-written. The title should not be “Why JavaScript is not a Worthy Competitor”, it should not solely pit V8 vs. Falcon, and it should probably go into a little bit of detail about the new compiler vs. the old one. I just re-read it, and could not find anything about the old compiler in there.

        If you really wanted to show off your new compiler, you would have benchmarked it against the old one. As it is, this just comes off as a troll article (you yourself admit that “JavaScript is ahead”, yet you deem it an unworthy competitor in the title).

    • Shawn says:

      “Flash is a slow piece of junk, … As someone who’s written flex applications for the past 3 years”

      What a load of drivle… Flash !=- Flex, as someone who can push 1100 sprites on an iPad 2, at 60 FPS, I can tell you that flash is not “slow”.

      Flex sucks, flex is slow. Don’t confuse that with Flash.

      And I just watched a HD video on my windows machine, 2% cpu usage in fullscreen.

  63. Phillip Kerman says:

    @Paul Roberts. It’s definitely possible to create a well tuned peformant flex app. You can (more easily) create a mess. And, inherently, I think Flex tends to create messes (for example, allowing you to place 20 datagrids on one page and have them all want to hog the CPU). Heck, you can create bad Flash code too–see it usually hits the 15 second timeout. Anyway, to compare JS to Flex is silly. Perhaps you could compare a huge framework in JS to Flex.
    Still, the value proposition that Flex offers is that it’s “easy”. I dare say, your awesome javascript applications were not built by the same folks who created your flex monsters. If you’re doing something that takes 3 minutes to compile, you’re probably doing something wrong. You can pre-compile parts etc. Anyway, if the premise is that Flash/Flex are bad softwares, then that’s just false. Arguably, the Flash player is not only one of the best pieces of software ever–it’s most definitely the most widely distributed.
    Anyway, so much of this discussion is moot.

    Finally, Avik–is this post really about “what you’re going to do to make AS faster”? Seemed like a general statement that JS is inherently not as fast as AS.

    • Avik Chaudhuri says:

      Well yes, the post is definitely trying to tell you that we *are* going to make AS run faster (that’s what I claimed in my reply above): type inference is just one step in that direction, which should already take us beyond JS. If you’re looking for what else we are going to *do* to make AS run faster: many posts to follow on that topic, in which I’ll outline further concrete steps.

    • Paul Roberts says:

      All of our flex code and javascript code has been written in house, so yes, the applications were written by the same 50 developers (minus the usual amount of staff turnover). We stuck with flex for 3 years, and tried very hard to make the technology work. But by the end, there was not a single person left that wanted to continue working with it.

      And I have to strongly disagree with you- the flash plugin itself is a terrible piece of software. I have never visited a site written in flash that did not bog my entire system down. Every single one of those sites, no matter how professionally done, is completely unusable on any phone in existence.

      We recently had a bug where Safari 5.1 users could not enter any text into our applications at all. Safari 5.0 worked wonderfully. The only workaround available required re-writing half of the application. Considering Apple themselves is our largest customer for this product, telling them to use a different browser was not an acceptable workaround. What the hell flash, I thought you were supposed to prevent these types of cross-browser issues?!

      • guest says:

        @paul roberts. The fact that you chose Flash/Flex as a solution for a product where the major customer was Apple, calls into serious question your architectural/business decision making. All the problems you describe with Flex sounds like the typical problems noobs face when they start Flex apps for the first time. Let me guess..your 50 developers are former J2EE enterprise devs that got into Flex because they thought AS looked like Java ? The only valid complaint is the longer compilation times, which is not a bad tradeoff for the unholy browser compatibility mess and framework (bet you have at least 4 JS frameworks involved).

        • Paul Roberts says:

          We built all applications for 3 years on flex, and Apple just so happened to become a major customer for one such product. It was impossible to foresee Apple being the biggest customer for the app before it was even built. And even if Apple weren’t involved, we should not have seen such a huge show stopper of a bug in a framework that touts that it avoids cross browser issues. Users couldn’t even log in!

          Yes, we are a java shop (I mentioned our backened code is Java), so those 50 developers are Java guys. What does it say about flex if 50 experienced Java devs can’t figure it out after 3 years? Is a guy with 10 years of Java experience and 3 years with flex still a “flex noob”?

          As for our JavaScript code, the only frameworks we use are jquery and jqueryui. In 6 months, we have seen a huge productivity boost and far fewer bugs. The applications load much faster and have been getting far better user feedback. No cross browser issues have hit production, quite frankly, because modern browsers are pretty good. If you don’t have to support ie6 or ie7, its a breeze. Write something in chrome and there’s a 99.5% chance that it will look and behave identically in ie8, Firefox, opera, and safari.

          And I could go on about all the ridiculous bugs in flex that we found, but the biggest complaints are really about run time and development speed. Why should we take twice as long to write something that runs half as fast? That to me is the real deal breaker.

          • guest says:

            Ok I am intrigued. Would you have a link this app that you could share?

            If I read you correctly, you converted a major Flex app into a HTML/JS app using just Jquery and JqueryUI.
            Would really love to know the details for e.g.

            1. Did you go from a Flex app i.e few swfs to a pure client side JS/HTML solution or did you go the dynamic JSP route with multiple pages?

            2. Assuming the Flex code was a large one with as you hint Cairngorm, how did you manage architectural concerns in JS without using any JS architectural frameworks? Or JS template libs? How about module management in JS ?

            3. Did you have Datagrids in the Flex app. If so what did you do for Datagrids in the JS version?

            Would love to learn more.


          • S says:

            @Paul Roberts

            Your failure in the Flash Platform is directly attributed to your team members.

            FLASH IS A GRAPHICS PLATFORM!!!!!!!!!!!!!!!!

            What on earth are you expecting by having a bunch of Java guys understand graphics programming? What on earth did you expect?

  64. Drew Wells says:

    Not sure why this appears in the JavaScript round up. If ActionScript were a superior solution the market would embrace it. Instead it has been a consistent security threat, runs extremely poorly (despite being compiled code), and has the cost the world a lot of battery life.

    While applauding the effort to benefit the internet community, you still need a plugin to run anything. My laptop sounds like it is taking off everytime you start, which is why I just turn you off now. My favorite flash feature? Click to enable! Too bad Google/FlashBlock had to teach you that one…

  65. phillip kerman says:

    A programmer with lots of Java experience will still need to learn the differences with flash player… Though I’ll be the last to defend flex as being a model of excellence. But I know devs who can make it work well. Anyway, you’re just plain wrong if you say flash player is always bad performing. Tell me if you’ve really never seen a quality example. I’ll dare say I’ve built some myself.

    I am very curious how you find js as a “language”. It’s cool and has some amazing momentum… But I doubt many would call AS a “bad” language.

    Personally I look forward to all the new stuff I get to do in js… But for certain, the REASON I’ll be using ns is simply client demand

    • Paul Roberts says:

      I think 3 years should be ample time to learn any platform. Hell, I would expect to be very proficient on any decent platform within 3 months. We’ve been on JavaScript for 6 months, and our JavaScript applications blow the old flex stuff away already. We were able to rewrite a reporting application that took a year to write in flex, in about 2 months.

      Also, please send me an example of a site that doesn’t lock up my phone or overheat my Linux box. Just running the old Pandora would make my CPU fans spin up on a core 2 duo, and that’s basically just playing an mp3! I had a 300mhz Pentium 2 that could do that back in the day, but flash can barely manage on a c2d?

      JavaScript as a language is fantastic, but you really have to watch out for some terrible oversights in its design. I would recommend reading JavaScript The Good Parts by Douglass Crockford, as he goes into detail about some of the terrible things about the language. Jslint is a great analysis tool that prevents you from making any of those JavaScript noob mistakes. Once you get into doing JavaScript though, you can do some things quite elegantly. Check out what some people have done on nodejs, which is really just v8 for the server side.

      Actionscript itself is not a bad language, but all of the tooling and frameworks for it that I’ve used have been terrible. Cairngorm for instance is a ridiculous over engineered monstrosity. Is it really any surprise that the company that brought you Acrobat, the worst PDF viewer in existence, can’t produce a decent development platform?

      • S says:

        Seems to me like your problem is not with the Flash Platform, but with Flex… I know it is hard to distinguish, but they are too different things. Your complaining about Adobe creating a development platform, well heck… who creates one for Javascript!!! LOL!

        Btw, your not forced to use Flex to build for Flash… I mean jeez I figured a man with your “experience” should know all of these things!

  66. Phillip Kerman says:

    @Paul Roberts I think we’re on the same wavelength for many things–I mean, picking on Acrobat… that’s my shtick. And Cairngorm IS over engineered for many things. But, it Adobe didn’t “bring” that or Flex (or Flash for that matter) to us. They bought the company BECAUSE of Flash… then foobar’d it beyond all fubar. Well, not quite. For the last 2 years I can safely say none of my projects using the Flash platform (I’d never touch Flex personally) were doing things that flat-out could not be done other ways (or at least could not have been done in any reasonable amount of time or effort).

    Face it, your 30 devs failed to make a Flash player project that could perform. There are only two logical possibilities: your did it wrong (that is, YOUR code was the cause) or you expected it to do something completely unrealistic…. even still, there are always work arounds. Now, if you just had a bug that was a real pain to deal with in one user configuration then I can feel your pain. I’ve run into many insurmountable bugs (which, to be fair, were often just fact-of-life… like, for example, the security restriction against text entry fields when in fullscreen. That bit me once but there’s nothing to do but think of work arounds).

    What perplexes me is that you really believe Flash can’t do high performance. What about Either google are a bunch of idiots (not the case) or they chose Flash because it can perform and solve the problem at hand. Yes, they’ll probably replace it one day–but the reason to use it now is that it can provide value. Besides, they know how to use Flash.

    It also perplexes me that your team of programmers were incapable of figuring out the tool. Perhaps what happened is you could point to specific flaws or killer bugs and just used that as an excuse? I’m sincerely stumped by this issue. I’m not saying you’re a bunch of hacks–but I KNOW you can build good apps in Flash. Perhaps it just wasn’t the appropriate tool for the job? Maybe server side made more sense for your project. I just wonder how you could continue after, say, 1 year if it was such a bad thing?

    • Paul Roberts says:

      Yes, Google does know how the best way to use Flash – SPARINGLY. Load up any Google site with a Flash Block plugin enabled, and you’ll see how little of their applications actually are Flash. Google Music for instance, has a completely functioning interface, you just can’t play any music. You can setup playlists and do everything else though. Google Maps only uses Flash for the street view level. I’ve heard that Google Finance only uses Flash for a couple of fancy graphs, though I’ve never been to that site. Even YouTube is fully functional without flash installed (it falls back to html5 video).

      To me, it looks like Google only uses Flash for the holes that HTML4 + Javascript cannot fill yet. In the case of Google Music, they are using Flash as a placeholder until the tag is mature enough for practical use.

      Think of it this way- if Google knew they were stuck with Flash for the actual audio part of an online music player, why didn’t they write the entire application in Flash? Pandora seemed to go down this route years ago, but they have since ditched their Flash interface for an HTML+Javascript one. Why do you think Pandora chose to go that route, given the investment in their old flash interface?

      To me, its obvious. I asked you to name ONE site from the ENTIRE internet, that was written in flash, that performed well. And you picked a site that was only about 5% flash.

      • guest says:

        1., appropriate and excellent use of Flash.

        2. The Hulu Desktop app 100% flash, beautifully done. Very performant, joy to use.

        • Paul Roberts says:

          Playing a video on my quad core i5 linux system takes 75% CPU usage. What is wrong with this picture? It wasn’t even HD.

      • S says:

        @Paul Roberts

        Just because you and your team cannot build a Flash app that works does not mean the platform isn’t good. Maybe it’s YOUR team that needs some help. Fact is your personal experience in the matter is just that, an experience good or bad, it should be taken as such. An anecdotal experience.

  67. Phillip Kerman says:

    @Paul Roberts upon re-reading what I wrote above I’d like to apologize for some of my tone where it was condescending. I can definitely disagree with some of your points without going there.

  68. Great discussion.Lot of things to observe about the action-script.

  69. Francois de Campredon says:

    I’m always so amazed to see that some people still can’t understand that they should use the right technology in the right place.
    That’s very clear that you should not use flash/flex to create “web site” event 2.0 one, however that very clear that when it comes to enterprise application, complex web application, or gaming, Flex/Flash have the upper hand.
    If you try to argue on that, you’re a technologie zealot, or someone who never worked with those technologies.

    @Paul Roberts : I’m sorry to say it, your developer team have failed, perhaps because of bad choice in your app architecture, or perhaps because you tried to do something flex haven’t been mean for, however, don’t blame flex for that.

  70. S says:

    @Francois de Campredon

    I wouldn’t let Flex off the hook that easily. Flex in all of it’s flavors, forms and incarnations is probably one of the worst poorly architected and written frameworks on the web. That goes without saying. However it is true that if one calls oneself a Flash Platform developer than you should be able to do quite nicely without the clusterf*ck that is Flex. Flex is dead, and I say good riddance!!

  71. Ben Fhala says:

    Fantastic post. i’ve been saying this for a long time but i thought no one agreed with me 😉

  72. Flexwiz says:

    Great post.
    Imo JS is a mess, only suitable for small scripts. No classes, no scope, no strong typing. Sure it has its uses, but it can never replace AS3. Flash and AS3 has immense community support and some of the best open source frameworks written for it (Robotlegs, anyone?) that make it a far better option.

    @S, @Paul Roberts : maybe Flex 2 and 3 where a mess, but Flex 4.6 is a great framework if you know how to use it properly. I personally wrote Flex apps runs blazing fast and super smooth. Ho, and Flex is very much alive, now an open source project under Apache.