[vessenes]

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

[pangram]

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.

[vessenes]

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.

[wslh]

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]

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.

[astrodust]

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.

[ootachi]

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.

[vessenes]

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]

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.

[vessenes]

Interesting. I didn't know this.

I understand that actually getting speed out of JS for binary data is still quite 'hacky' though, for instance Fabrice Bellard used Typed Arrays extensively implementing his Linux-on-Javascript project: http://bellard.org/jslinux/tech.html

[VMG]

but you have to admit this isn't very obvious or well documented

[adgar]

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

[ootachi]

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]

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.

[jasonwatkinspdx]

Statically.

[kaushiks]

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.