I can see how this would allow more flexibility, since a codec could be downloaded at run-rime, which would remove the need for media to only be packaged in codecs with native, cross-browser support.
But is there any chance this could be even close to as efficient, CPU or power-wise, as the current standard native browser codec support?
I don't like how this article is written at all. It leaves a bias afterlook that Mozilla's goal here is to create a toy. JavaScript is the fastest interpreted language and plans are out to make it even speedier. There's a reason why "the future" is emphasized.
Perhaps I am biased as a Node.js programmer, but I do believe this is a good thing. JavaScript is seriously pretty sweet. I do like the design of the language. There are features that outblow many other languages.
Citation needed
http://en.wikipedia.org/wiki/JavaScript_engine#Performance_e...
asm.js promises speed 2x slower than native code. For interpreted code, that is amazing.
It's been a while since I rolled up my sleeves and ran various algorithms in js vs lua vs py (pypy was speedy as well last I checked).
asm.js isn't dynamically typed afaik, so I think of a fair comparison as v8 vs luajit
A nitpick: Current Javascript implementations are fast specifically because they are not interpreted. Look at V8 or JagerMonkey; those are JITting compilers, not interpreters.
a) fitting perfectly in the business model of Mozilla Corp.
b) the voluminous and unwavering support they can expect from their fan base.