Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Slashdot Deals: Deal of the Day - Pay What You Want for the Learn to Code Bundle, includes AngularJS, Python, HTML5, Ruby, and more. ×

Submission + - Web browser vendors announce WebAssembly: bytecode for the web

NotInHere writes: The vendors of WebKit, Chromium, Edge, and Firefox announced their united effort to create a binary execution format for the world wide web. Like the previous projects pnacl and asm.js, WebAssembly features near-native performance, but without the vague specification pnacl had, or the space-consuming asm.js format, which had a 20x parsing overhead compared to a bytecode format (now arrays can be used instead of lookup maps, and no heavy decompression step). Besides wider adoption as its plugin-less, and an open specification, the main advantage of this project over plugin based solutions like java applets has been characterized by Mozilla's Luke Wagner as:

[T]he API surface area is that of the Web platform (e.g., WebGL for graphics) and thus WebAssembly use cases will contribute to driving forward the whole Web platform.

The inventor of javascript, Brendan Eich, writes in his blog entry covering WebAssembly about the polyfill plans:

It’s crucial that wasm and asm[.js] stay equivalent for a decent interval, to support polyfilling of wasm support via JS. This remains crucial even as JS and asm.js evolve to sprout shared memory threads and SIMD support.

He further writes:

Yes, we are aiming to develop the Web’s polyglot-programming-language object-file format. [...] wasm should relieve JS from having to serve two masters [FAQ entry here].

Most likely due to Mozilla's envolvement, WebAssembly even tries to address the "binary" barrier built up when dealing with WebAssembly on a client.

I have a theory that it's impossible to prove anything, but I can't prove it.