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.
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.