4 ms·

At best, this reeks of like 2000-era Microsoft, "Why does everybody get so excited about Javascript still? ActionScript is way better! Duh!" As far as actual p

At best, this reeks of like 2000-era Microsoft, "Why does everybody get so excited about Javascript still? ActionScript is way better! Duh!" As far as actual points in the fine article -- a test using some sort of strongly typed data on an unreleased actionscript vm ran three times faster than v8 running similar code. I'm not shocked at all, and think Javascript could badly use at the least some type hinting, personally. But, this author is at best just missing it, at worst is misleading others. I recently ported a Flex app to HTML5. Frame rates quintupled on a modern browser; in a real, mixed-use environment, ActionScript-based tools, interpreted with the Flash or Flex runtime, are roughly one-fifth the speed in the modern browser. If this speed delta trended the other way, Flash would still be vigorously defended by developers all over the world who would say "we have to have this speed, don't take it away from us!"

astrodust 15y ago
This is what I'm having trouble believing. If ActionScript can be "compiled to death", where in this case "compiled" means "to bytecode" then presumably the same thing could happen to JavaScript. In the V8 environment it should be possible to aggressively optimize the code in question with various command line options. Where is -O5? The real problem is a lack of an open-standard for JavaScript bytecode. Being able to serve "pre-compiled" JavaScript would go a long way towards improving performance.
- vessenes 15y ago
  Well, the problem (one problem) is that Javascript has no typing system. This makes running valid javascript code super, super slow at times. You can't promise to a javascript interpreter that you will always and only use the variable i_am_only_ever_an_integer as an 8 bit integer. This makes lots of things super slow.
  - ootachi 15y ago
    Of course you can promise types to the JS engine. Ints in particular are easy. With modern type-inferring JITs like SpiderMonkey, an expression like "var x = 3;" will infer x to int, and there will be no type checks or unboxing. In more complex cases, you can add "|0". For example: function f(x) { x = x|0; ... } This has the effect of forcing an int interpretation for the argument, and there will be no type checks or unboxing performed thereafter.
    - VMG 15y ago
      but you have to admit this isn't very obvious or well documented
    - adgar 15y ago
      > Of course you can promise types to the JS engine. Because a variable can always change types, it's actually trivially proven that in a dynamically-typed language, there will always be programs in which the type cannot be inferred.
      - jasonwatkinspdx 15y ago
        Statically.
      - ootachi 15y ago
        Well, statically-typed languages have a "dynamic" type too. Consider void * in C and C++ and Object in Java and C#. You have to downcast to do anything with them. That's the equivalent of what JS is doing with its dynamic typing. The basic difference is that the "dynamic" type is the default in JS, and the static type is the default in statically-typed languages.
        georgemcbay 15y ago
        The premise of this article is that Javascript's pure dynamic variables lead to slowness. I'm not sure what your point with this post was because if you litter your C/C++ code with non-static casts, it is also going to be much slower than code without casts.
        ootachi 15y ago
        The parent comment was pointing out that there exist programs in JavaScript in which the types cannot be inferred. All I was saying was that this is not unique to JavaScript, or to dynamically typed languages generally.
    - vessenes 15y ago
  - kaushiks 15y ago
    That is not true. I'm not entirely sure what you mean by "no typing system" so I'll go ahead and assume what you likely meant - no static type system. Optimizing code written in a dynamically typed language is a pretty well understood problem (now) thanks to the SELF research at SUN and more recently the V8 Javascript engine. Both VMs employ type profiling at runtime to figure out what the compiler should assume the type of a dynamically typed variable should be. It can then emit code that treats a variable like it always has the profiled type - like a C++ compiler would. When such an assumption is broken at runtime, implementations typically fallback to an unoptimized version of the code (V8) to execute the rest of the continuation. Well written code is expected to achieve type stability pretty fast making the fallback overhead insignificant.
- ootachi 15y ago
  Nonsense. JavaScript bytecode would still be dynamically typed. At best a JavaScript bytecode standard would be equivalent to a compressed AST. That still might be a useful thing to have, but it wouldn't improve runtime performance.
  - deleted 15y ago
    [deleted]
pangram 15y ago
Out of interest, is there anything you can share about the particulars of your application? We did the same Flash vs. HTML5 analysis in the context of Facebook games, but in our experiments it looked like Flash still won handily in terms of performance.
- wslh 15y ago
  Not just that, even the Google Chrome support for SVG is terrible, it crashes very quickly if you draw a lot of nodes. I also found very simple bugs like moving a SVG objects leaves a trail behind. A good vectorial support is needed to replace flash.
  - untog 15y ago
    It's a constant disappointment to me that Canvas is favoured over SVG. Just drawing simple shapes and moving them is so much more complicated with Canvas.
- vessenes 15y ago
  It was a business intelligence app; the front end rendered graphs and charts based on data over Zend. We staged out of that architecture by implementing a REST endpoint on top of Zend, and moved our graphing over to the (now-superceded) protovis library. Our engineers weren't used to worrying about data transfer, so we had to do a little bit of engineering work on the JSON side once we switched out, but the graphs, charts and rendering are VASTLY faster. That said, it could well be the Flex runtime that added all the badness; flash games definitely render faster than our app did.

astrodust 15y ago

This is what I'm having trouble believing. If ActionScript can be "compiled to death", where in this case "compiled" means "to bytecode" then presumably the same thing could happen to JavaScript. In the V8 environment it should be possible to aggressively optimize the code in question with various command line options. Where is -O5? The real problem is a lack of an open-standard for JavaScript bytecode. Being able to serve "pre-compiled" JavaScript would go a long way towards improving performance.

vessenes 15y ago
Well, the problem (one problem) is that Javascript has no typing system. This makes running valid javascript code super, super slow at times. You can't promise to a javascript interpreter that you will always and only use the variable i_am_only_ever_an_integer as an 8 bit integer. This makes lots of things super slow.
- ootachi 15y ago
  Of course you can promise types to the JS engine. Ints in particular are easy. With modern type-inferring JITs like SpiderMonkey, an expression like "var x = 3;" will infer x to int, and there will be no type checks or unboxing. In more complex cases, you can add "|0". For example: function f(x) { x = x|0; ... } This has the effect of forcing an int interpretation for the argument, and there will be no type checks or unboxing performed thereafter.
  - VMG 15y ago
    but you have to admit this isn't very obvious or well documented
  - adgar 15y ago
    > Of course you can promise types to the JS engine. Because a variable can always change types, it's actually trivially proven that in a dynamically-typed language, there will always be programs in which the type cannot be inferred.
    - jasonwatkinspdx 15y ago
      Statically.
    - ootachi 15y ago
      Well, statically-typed languages have a "dynamic" type too. Consider void * in C and C++ and Object in Java and C#. You have to downcast to do anything with them. That's the equivalent of what JS is doing with its dynamic typing. The basic difference is that the "dynamic" type is the default in JS, and the static type is the default in statically-typed languages.
      - georgemcbay 15y ago
        The premise of this article is that Javascript's pure dynamic variables lead to slowness. I'm not sure what your point with this post was because if you litter your C/C++ code with non-static casts, it is also going to be much slower than code without casts.
        ootachi 15y ago
        The parent comment was pointing out that there exist programs in JavaScript in which the types cannot be inferred. All I was saying was that this is not unique to JavaScript, or to dynamically typed languages generally.
  - vessenes 15y ago
- kaushiks 15y ago
  That is not true. I'm not entirely sure what you mean by "no typing system" so I'll go ahead and assume what you likely meant - no static type system. Optimizing code written in a dynamically typed language is a pretty well understood problem (now) thanks to the SELF research at SUN and more recently the V8 Javascript engine. Both VMs employ type profiling at runtime to figure out what the compiler should assume the type of a dynamically typed variable should be. It can then emit code that treats a variable like it always has the profiled type - like a C++ compiler would. When such an assumption is broken at runtime, implementations typically fallback to an unoptimized version of the code (V8) to execute the rest of the continuation. Well written code is expected to achieve type stability pretty fast making the fallback overhead insignificant.
ootachi 15y ago
Nonsense. JavaScript bytecode would still be dynamically typed. At best a JavaScript bytecode standard would be equivalent to a compressed AST. That still might be a useful thing to have, but it wouldn't improve runtime performance.
- deleted 15y ago
  [deleted]

pangram 15y ago

Out of interest, is there anything you can share about the particulars of your application? We did the same Flash vs. HTML5 analysis in the context of Facebook games, but in our experiments it looked like Flash still won handily in terms of performance.

wslh 15y ago
Not just that, even the Google Chrome support for SVG is terrible, it crashes very quickly if you draw a lot of nodes. I also found very simple bugs like moving a SVG objects leaves a trail behind. A good vectorial support is needed to replace flash.
- untog 15y ago
  It's a constant disappointment to me that Canvas is favoured over SVG. Just drawing simple shapes and moving them is so much more complicated with Canvas.
vessenes 15y ago
It was a business intelligence app; the front end rendered graphs and charts based on data over Zend. We staged out of that architecture by implementing a REST endpoint on top of Zend, and moved our graphing over to the (now-superceded) protovis library. Our engineers weren't used to worrying about data transfer, so we had to do a little bit of engineering work on the JSON side once we switched out, but the graphs, charts and rendering are VASTLY faster. That said, it could well be the Flex runtime that added all the badness; flash games definitely render faster than our app did.