That's a pretty big leap from "requires C/C++"
It does require C/C++, as Cogman said, asm.js requiring type declaration and memory management. At some point cross compiling C#, Java and Python to it might be possible but not until at least ES6's final spec which should be the end of the year, and it will be quite a while until after that when everything is implemented for everyone's favorite flavor. Probably a couple years later at minimum.
If you have an idea that could use the speed and you're competing in the marketplace, it's an understatement to stay that a couple years can be too late.
If asm.js does see widespread use, it will likely be created from already mainstream web app languages, Java/Ruby/.Net/Python
Little Bobby's Geocities site won't require it. But if it gives you an advantage over your competition, then I wouldn't bother waiting to get started.
Because you'll be waiting a long time and there's plenty of people who can program in C or C++ today and don't need all that hand holding.
Mozilla will introduce GC and structured data based on ECMAScript6, at which point it will be possible.. but we're looking down the road quite a ways. There's enough C and C++ programmers out there that if you have a serious product I wouldn't bother waiting that one out. Use Emscripten
https://github.com/kripken/emscripten and get to it.
The asm.js demo accomplished a whopping 10 frame per second improvement on a first person shooter running in the browser. About as niche an application as you can get. To take that and say "the next wave of web apps will be written in C++" is a bit of a stretch.
I guess if you aren't looking down the road this might be true. But the video game market is simply one market, it isn't niche, it's a 25+ billion dollar industry. And there's many other concepts that haven't been implemented yet online because of limitations imposed by the webstack. asm.js is in my opinion, targets one area that's been lacking as providing the best way to eliminate any client-side processing barriers.
If you don't think asm.js will allow new types of web applications and the next generation, then I don't really have anything to say on that (IMO) conservative stance.
Your vote is nay against asm.js, my vote is yea. Because it works on asm.js enabled browsers and those which are not. It's a no brainer for anything doing processor intensive tasks.
The speed at which regular old JS can do things on a canvas or a DOM in a modern browser is more than enough performance for 99.99% of the web apps out there. Yes I went to four nines.
If your web application is data heavy rather than processing limited, then the database is doing all the work, sure. But there's a lot of concepts that have not even been implemented, the web isn't done advancing as a software medium.
Right now asm.js generated by emscripten is 4-5x slower than native code, but this is all in progress, the final target is 2x slower than native code. Which in my book will easily be fast enough for anything, with today's hardware.
If you're using a modern browser like Firefox 22+ (I don't think any others support asm.js at the moment), the JS engine immediately recognizes asm.js code at compile time and compiles it to assembly instead. It's never ran through an interpreter.
Mozilla is truly pushing the web forward yet again in a non-proprietary way with this one- asm.js runs whether the browser knows anything about asm.js or not. It's not the right technology for an Angelfire or Geocities site though. Maybe the performance gains will trickle down to Python/C#/Java crosscompilers in time, for anyone needing performance today for a cutting edge web application you're looking at what will usher in the next generation of webapps that matter.
Facebook
Twitter