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.

Comments

What is webassembly? Never heard of it before...

[fishscene]

Is this the whole HTML 2.0 thing where it's not HTML at all, but compiled code to "run faster"? If so, I want no part in this. The Web is perfectly speedy, but it's the Ads and garbage slowing it down. Combined with the MPAA and RIAA mafia's, ALL 4 major browsers simultaneously announcing support... and my conspiracy meter goes off.

Re:We got rid of flash and applets

[beelsebob]

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

A reason for concern

[vivaoporto]

This development can very much be a big reason of concern. Setting aside the fact that this will bring closed source software to an arena where it is mostly non-existent (the scriptable part of the web) this will also open a new vector for malicious scripts to hide.

If it is already a vector today imagine when it is a binary that you cannot even cursorily inspect before running.

Re:A reason for concern

[erapert]

If you're using nodejs then try uglify-js. On Ubuntu, assuming you already have nodejs installed, you can install uglify with:

> sudo npm install -g uglify-js

And then get the options:

> uglifyjs -h

So if I have a source file foo.js which looks like this:

> function foo(bar,baz){console.log("something something");return true;}

I can beautify it like so:

> uglifyjs foo.js --beautify --output cutefoo.js

uglify uses spaces for indentation by default so if I want to convert the 4-space-indentation to tabs I can run it through unexpand which Ubuntu 12.04 comes with:

> unexpand --tabs=4 cutefoo.js > cuterfoo.js

so after all this I wind up with a file that looks like so:

function foo(bar, baz) {
console.log("something something");
return true;
}


(when will /. support markdown for comments?)

Re:We got rid of flash and applets

[vivaoporto]

and any browser can implement

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.

Re:What is webassembly? Never heard of it before..

[zlives]

don't worry, it will never be used for DRM or adware

Re:What is webassembly? Never heard of it before..

[peragrin]

This is Web 3.0. The search for more money.

With ads running at assembly speeds they can play a dozen videos ads per page at the same time.

Re:What is webassembly? Never heard of it before..

[firewrought]

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.

Re:my-pntbtr-add(list_eria)

[U2xhc2hkb3QgU3Vja3M]

It's the one platform that's OS-independant, at least in theory.

It gives me hope that all four major browsers are in this together but at the same time it's going to give me nightmares about what the advertising companies are going to do with it.

I hope nobody messes up the sandboxing of this whole thing.

Re:What is webassembly? Never heard of it before..

[Darinbob]

Don't forget that Javascript is slowing it all down too. Content loads fast, but the web-as-an-application-framework is what's wrong with the web. This is essentially Java applets reinvented but with the wrong lessons learned.

Re:What is webassembly? Never heard of it before..

[paulpach]

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.

Re:What is webassembly? Never heard of it before..

[wonkey_monkey]

a huge ass plugin

[hyphenation needed]

Re:Hard to find a worse route...

[Anonymous Coward]

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.

WebAssembly isn't that impressive (yet)

[Elledan]

Last December I took an extensive look at ASM.js and WebAssembly, from the point of view of an old-school C/C++ developer, and wrote an article about it: A look at asm.js and the future with WebAssembly.

The short of it is that while interesting, the JavaScript runtime both asm.js and WebAssembly run in impose such major limitations on the applications being written that its actual uses outside of game ports is fairly limited.

Re:my-pntbtr-add(list_eria)

[windwalkr]

I'd disagree, for the most part-

* Consumers are asking for something like this. Not everywhere, and often because they know it's generally not up to them, but platform lock-in is a pain for many people. "I have to buy a PS4 for this game." "This product isn't going to support Mac." "Only on iOS." "Requires Flash."

* Devs are definitely asking for something like this. "Can we afford to port to platform X? Can we afford not to?"

How things are now, we're talking about a lowest-common-denominator problem, so only a small subset of problems are solved. Hopefully this will improve over time, until the majority of problems are solved and only edge-case problems require specific platforms.

Re:my-pntbtr-add(list_eria)

[non0score]

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.