Mozilla can produce near-native performance on the Web

BTW, C/C++ code that is compared has multithreading and SIMD capability disabled. In the third page they benchmark asm.js and native with multithreading and SSE enabled. It shows upto 50x slowdown! Not exactly sure what the point of a benchmark without multithreading is. I mean anyone writing performance sensitive apps will use MT right? (given JS is single threaded, it seems this is a dealbreaker).<p><a href="http://cdn.arstechnica.net/wp-content/uploads/2013/05/classic-native-v-optimized-v-asmjs.png" rel="nofollow">http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...</a>

For most applications JS doesn't need to get any quicker. What makes web apps feel like swimming through molasses is the DOM.<p>Even something as simple as getting a Div to follow the mouse on anything but the simplest of pages is impossible to do without incurring ridiculous lag.<p>I don't know enough about them, but it seems that maybe Web Components may offer some answers by encapsulating mini Document trees which presumably exist in isolation from other components thereby reducing the penalties of dynamic CSS.

The fascinating thing about this is that they didn't write a new JIT for asm.js. It's just their existing JIT with more information and a few new tricks. Among other things, this means that it doesn't yet have a lot of the fancy optimizations that C/C++ compilers typically have in their backends, like clever instruction selection or register allocation. It's already impressively fast, and it has the potential to get even faster.

I would much prefer having a sane new language replacing JavaScript instead of this hack to improve performance. A new language could provide the same performance advantage and make writing web applications much more pleasant.<p>Admittedly it is harder to introduce a new language across all (major) browser but I think it would really be worth it.

&#62; Emscripten builds taking between 10 and 50 times longer to compile than the native code ones.<p>Hey, this is fatal. With this massively long iteration time, you can't run actual big projects. Only executing 1,000,000 lines of C++ code is not enough. We care the build time as well as the perforamnce.<p>BTW, have you heard that the next Haswell processors can get only 5% performance improvement? We should assume that we have no free lunch anymore. One of the UNIX philosophies is already broken.

It seems Mozilla and Google are moving more and more toward their own browser specifications and mechanisms. Microsoft and Netscape did this in the 90s, and it ended up causing nothing but pain.<p>Optimizing JS is interesting, but creating browser-specific applications of code meant for a web audience disturbs me. I don't want a repeat of the first browser wars. Hopefully Mozilla will work toward w3 standards in this effort, since Google clearly hasn't with Dart.

I really disagree with the idea of ASM.js. I think that the whole asm.js thing has got people more people confused into thinking that they can't build fast applications in regular JavaScript.<p>That is not true. JavaScript code is usually compiled to native code now and is very fast -- generally much faster than Ruby and Python.<p>I wish Mozilla and other core browser teams would focus on better WebGL support in more drivers and devices as well as better JavaScript engines -- for example Safari especially stands out with their deliberately crippled performance, and Microsoft with their deliberately crippled featureset.<p>The great thing about the web is convenient APIs like WebGL and nice languages like CoffeeScript. ASM.js negates that for no good reason. There are huge opportunities for exciting WebGL games which don't require the most optimized possible JavaScript, that just haven't been explored yet, and within a couple of years ordinary hardware will go much faster anyway.

It feels the most interesting use of asm would be to bring existing C code into javascript and have it run at reasonable speeds. Things like small (or not) database engines, authentication or encryption libraries, data parsing utilities etc...

Near native performance is a very good thing especially in the fields such as game development.<p>However, it's a pity that Mozilla doesn't address the main problem with the web platform, the lack of good platform and the set of API, something like Java or .NET provides. There are a large number of good javascript applications (Google docs, GMail, etc), which are produced by heroic efforts of the teams who created them. The same effort could have been expended on hundreds more useful software, if JavaScript was replaced by something more adequate.

It seemed that the general idea of web being slow is so polarizing that each and everyone of us can't even pinpoint where the problem is. I suspect the problem is a multidimensional one.

tl;dr: its not as fast as native but its much better than AT expected, and actually within 2x the speed of native.<p>Also its slightly slower (a few %) than regular JS on browsers without asm.js support.

It would be interesting to see an implementation of this on ARM platform. Firefox OS powered mobile device would be really promising with this optimization.

I think it's becoming clear that there is room for two classes of web language: one for general use (JavaScript) and one for high performance applications or games. Let's get a real language alternative, free of half measures or compromises.

What do developers want for a development environment these days? Is C/C++ the next wave of web development? Tooling is a lot better than when I did it 15 years ago. Dart, however, seems like a friendlier environment but it probably won't be as fast a C++(asm.js).

I wonder how the Internet would have looked like if it had developed the way that Alan Kay proposed (i.e. a browser as a mini-operating system). It's quite possible that we'd have much better performance (among other things) from the start.

Why dont they just insert regular C/C++ source code inside HTML and be done with it? Eventually the browser is just going to be a download manager that downloads executable code and runs it locally :P

No it can't. C is not the speed limit. Top native performance is achieved by an ungodly combination of SIMD intrinsics, compiler-assisted optimization, cache-aware data-structures and assembly.

Why don't they first produce near-Chrome performance for their browser? Every time I use Firefox, it slows down to a snail's pace and eventually crashes if there are more than 4--6 tabs open.

Finally, I can write all my web apps in C/C++. Dream come true!

&#62; It's a limited, stripped down subset of JavaScript that It's a limited, stripped down subset of JavaScript that the company claims will offer performance that's within a factor of two of native—good enough to use the browser for almost <i>any</i> application.<p>Except for running webpages scripted with Dart. It's not fast enough for <i>that</i> application apparently. <a href="https://news.ycombinator.com/item?id=3095519" rel="nofollow">https://news.ycombinator.com/item?id=3095519</a>