Slashdot Mirror
Major Browsers Add Experimental Support For WebAssembly (thestack.com)
An anonymous reader writes: Four major web browsers have announced support for the near-native compiling technology WebAssembly, and collaborated to bring an initial common game demo of Angry Bots, running via Unity and WebAssembly, to experimental builds of Chrome, Firefox, Microsoft Edge and, shortly, Safari. WebAssembly was launched last year in a joint project between Microsoft, Mozilla, Apple and Google as a potentially more efficient route to assembly-level performance than asm.js, which is in itself a low-level subset of JavaScript.
Up until someone finds a way to introduce either a patent encumbered functionality (like H264) or one inherently proprietary (like EME for DRM) to poison the well and keep real independent implementations out of scope for everybody else except the incumbents.
Aren't the vast majority of web APIs text based anyway? Why would webassembly change anything about that?
I am a game developer and I am really excited about webassembly.
There are many challenges a game developer faces today:
1) Javascript has awful performance. Some game related code such as procedural content generation is very cpu intensive, and it would just take too long in javascript. Webassembly is meant to _always_ be compiled to native code and it is statically typed which allows the compiler to optimize the code much better. It will perform many times faster than javascript.
2) Javascript does not support threads. This is one stated future goal for webassembly. This is useful when you want some work to happen in the background (again, procedural content generation).
3) Plugins suck. If I deploy my game, say with the unity plugin, I am asking my customers to download a huge ass plugin in order to run my game. Some won't because they don't trust the plugin, some wont because the download takes to long, some wont because they don't have the required permissions, some won't because it does not work in their platform. Whatever the reason, I am losing a lot of potential users by using a plugin even if I get better performance. Webassembly will not require plugins.
4) Download time. If I compile a game to asm.js, just the game engine runtime require several megabytes downloads. Webassembly does reduce the size of the download significantly. This is one of the stated goals. This is one of the reasons webassembly is binary instead of text based. The smaller the download, the faster the player can start playing and the less users I lose.
5) Startup time. If it takes 30 seconds to parse all the asm.js or javascript before the game actually starts, that is an eternity, and many people will actually close their browser before the game starts. Webassembly is binary because parsing it will take orders of magnitude less time than parsing the equivalent asm.js.
6) Browser compatibility. Today, only 2 browsers are serious about asm.js: Edge and Firefox. webassembly is being developed by all major browsers. It is also quite likely it will be implemented in mobile or even outside browsers altogether.
So yes. I am excited about it. It will make may games more accessible to my users.
You're in luck, the workflow is typically C/C++ (or some other language than JS) -> Emscripten (or other compiler that targets ASM.js / WebAssembly.
Then the browser notices the "use asm" tag, and validates a code block as ASM.js / WebAssembly. If it conforms to the strict standards of no GC, arraybuffer memory accesses, no function pointers, etc. then the code is compiled into machine code (and cached for faster loading next time).
So it's not Javscript programmers, but C programmers, who are running code in ASM.js / WebAssembly, via LLVM's translation.
The cool thing is that ASM.js is just a subset of Javascript. It's pretty gnarly to program in directly because of the kludgey way it handles data types. However, this means that if the browser doesn't understand ASM.js then it just runs it as regular javascript and it still works.
This is what has been needed to transition away from Javascript. ASM.js lets me opt-out of Javascript's slow GC and even slower prototype system (which is a pain to optimized, since objects can change their properties at any time).
I've taken to implementing some things, like SHA256/512 hashing functions in ASM.js by hand, and get even better performance than running the C code through LLVM and into ASM.js. However, I'm a language designer and code in many other languages than just Javascript.
Just because I know how to code in Javascript doesn't mean I can't proficiently code in C, Perl, Lua, Python, C++, Java, COBOL, Fortran, FORTH or even x86, AMD64, or ARM assembly. In fact, it takes people like me to get performance out of languages. Some say that the OS and hardware is irrelevant, users don't care about the OS or hardware, they just care about what software runs on it. An OS is just an API for talking to hardware. Well, I don't care about languages, languages are irrelevant, they're just APIs for talking to hardware. Let me at the machine code.
Google's NaCl had a good approach: validate a subset of opcodes that were guaranteed not to be able to escape a sandbox. However, it tied itself to x86 opcodes. WebAssembly wants to do the same thing in a cross platform way. I think it's the right way all programming will go (is going, has gone) -- code compiles to cross platform bytecode and then the bytecode is translated per machine (Android does this, Perl6 uses this strategy, There's Java, C#, etc.).
TL;DR: All javascript programmers are writing in ASM.js already, since ASM.js is a subset of Javascript.