Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I really wish we had a proper 'web assembly' instruction set to compile to. JavaScript has proved itself to be a surprisingly adequate language over the years, but there is only so much optimization you can do with its language specification.


But that's kind of the whole point of asm.js - it defines a subset of Javascript that is far more optimizable than the full Javascript specification. Do you feel that there are still parts of the asm.js spec that are holding optimisations back? If so, I would be interested to hear your thoughts as to what the problems are.


There is a proper 'web assembly' instruction set. It's Google 's Portable Native Client [1]. The problem with this solution is that Google is the only one supporting it. But there other players in the web. Creating such a standard making all of the vendors happy might be impossible.

ASM.js might not be the perfect solution, but it has the huge advantage of being compatible with all major browsers. Practicality beating purity is a common pattern in Web's history.

[1] http://www.chromium.org/nativeclient/pnacl/introduction-to-p...


The real-world differences between asm.js and PNaCl are really not that big (basically only whether threads are true POSIX threads, or WebWorkers). Here's a (shameless plug) demo page which has the same demos as emscripten and PNaCl compiled from the same C++ code (warning: most of the PNaCl demos need the latest Chrome Canary): http://floooh.github.io/oryol/


The sandboxing provided by NaCl is nice, but I'm not sure binary portability is really a worthwhile goal -- I think we really want cross-compilation, native binaries and the OS providing most of the sandbox.

That way we get maximum performance on the hardware we're targeting (not the "lowest common denominator" of common bytecodes), an ability to run self-modifying code if we want to send a JIT down the wire...


A bit off-topic, but I would really like to see (P)NaCl apps directly supported on Android outside the browser, no need to mess with the NDK or Java. One can dream, right? :)


The history of the web is very much a series of mad hacks and patchups cobbled together to keep the whole thing progressing and evolving - the ultimate "legacy application" if you will; the endearing zaniness of asm.js is just another milepost in this well-trodden road.


In the 90ies we thought it would be Java.


And it looks like that in the future we will have something like JVM and its classloaders. Just with different names (LLVM? v8? RequireJS? JS AMD?) and a lot more kludges. And without Gosling, Joy and Steele.


In the future JS-ASICs will define what you can do in the web. People will complain "123JS ASIC is the new IE6".


And poor real world performance will be blamed on lingering 16 bit code in Windows!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: