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.
Right, now we have an open standard byte code that any language can target, and any browser can implement, along with several competing implementations, and lots of eyes looking at the security of those implementations.
So yeh... HELL YEH, NOW THIS!!!!
don't worry, it will never be used for DRM or adware
It's a replacement of two previous ideas... Mozilla's asm.js ("let's specify a subset of JavaScript that can run faster") and Google's NaCL ("let's ship x86 code directly to the browser"). As best I can tell, the replacement resembles putting a Java/.NET-style virtual machine into the browser to execute a new form of bytecode (.wasm files).
This is good for speed, which is in turn good for developers who want to deliver complex ("Photoshop-like") apps from the cloud.
It's bad for security (expanded attack surface), and it's bad for privacy (more ways to fingerprint the browser).
It's a wash for transparency: today's minified JavaScript is pretty much unreadable anyways.
Probably my biggest concern off the bat is wondering how the ecosystem for web API's is going to work when everyone's developing in their own favorite programming language. Traditionally, JavaScript has been a uniting force in this regard.
-1, Too Many Layers Of Abstraction
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.
a huge ass plugin
[hyphenation needed]
systemd is Roko's Basilisk.
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.
That's a pretty naive interpretation of Webassembly. Let's address your comments.
1) Yes, the target audience are in the native code camp. But outside of mobile, there is no good delivery mechanism, other than the web. This is basically doing that: brining the web to native apps.
2) There is no cross platform sandbox for running native apps, and this delivers on that. All modern browsers at least attempt at security, whereas non mobile platforms offer very little in terms of security against native apps.
3) Computers aren't getting "fast enough" (or much faster, for that matter). Especially not for mobile, which will always be slow because of power requirements. This spec will greatly help with that.
So it serves many purposes, and I think is a wonderful boon to the web.