4 ms·

Can anybody ELI5? The documentation is pretty fluffy. Does WebAssembly actually open up any new API hooks? I get that its a clever way of transpiling existing

by fergie 9y ago

Can anybody ELI5? The documentation is pretty fluffy. Does WebAssembly actually open up any new API hooks? I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already? Whats new avenues of development is WebAssembly expected to open up? Is the whole point just to enable an easy way to compile games made on other platforms (Unity) to the web?

SirHound 9y ago
I can address at least the first misconception here - this isn’t transpilation to JS. This is native code that has browser APIs exposed to it, so in theory there should be massive performance wins.
- poizan42 9y ago
  This is also a misconception, it is just a bytecode. asm.js is already running at around 50% native speed so there is no massive performance wins to find. What you get with WebAssembly is reduced startup time because it doesn't have to be parsed first. The really exciting thing people should be talking about is not WebAssembly but the general availability of SharedArrayBuffer[0] which finally makes it possible to run "foreign" multi-threaded code efficiently. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
exDM69 9y ago
WASM is used to run native code in the Web browser without going through JavaScript. With it, it should be possible to run code at near-native performance in the browser. WASM is an intermediate representation which is output by your compiler (of your favorite language) and consumed by the browser's compiler to emit native code. WASM is a bit similar to LLVM IR, but it's architecture independent. Compare this to, say, LLVM and Clang. Clang (the C compiler front end) will read C code and emit LLVM IR. LLVM (the compiler backend) will read LLVM IR and emit assembly code for your CPU. With WASM, the developer will run the "front end" and distribute the WASM code over HTTP and the web browser will run the backend and turn WASM into native assembly code. > I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already? No, WASM code is not JavaScript at any point. ASM.js is a predecessor to WASM that was a compiler-friendly variant of JavaScript that can be compiled to native code.
- fergie 9y ago
  Oh I see- that makes sense.
- qaq 9y ago
  But is this how it is implemented by actual browsers? if memory serves v8 is pretty much reusing most of JS VM for WASM?
  - exDM69 9y ago
    Yes, the browsers do share parts of their JavaScript execution engine with WASM. Which makes sense because WASM still needs to interact with JS. That doesn't mean it can't be fast or start quickly (or at least quicker than asm.js). From the developer's point of view that doesn't matter. You're delivering WASM and not C or JS code over to the clients.
  - marcosdumay 9y ago
    WASM requires a much simpler VM than JS. It doesn't take most of a JS VM.
steveklabnik 9y ago
WebAssembly is a specification of a small assembly language. This language can call into functions in its host environment. The "web" part is that all evergreen web browsers have implemented this language, and you can use it from inside your browser, and call JavaScript functions into it. This means that WebAssembly is actually broader than just the web; for example the Etherium folks have been discussing using wasm as their language to script their blockchain. It doesn't currently open up any real new API hooks; it's mostly about being an efficient language for computation. You get near-native performance in the browser. In the future, it may or may not grow more hooks directly into the web platform, rather than needing to call into JS to do so.
Fredx87 9y ago
Today the browsers virtual machines can work only with Javascript code. That means that if you want to use another language you have to convert in to Javascript, and you are obviously limited by the features of Javascript. The goal of WASM is to provide a language similar to Assembly (or bytecode of Java) that can be understood by the virtual machines of browser, and so to have a new way to compile languages and use them in the browsers. WASM can also be optimized better, having more features than Javascript (for example javascript uses only double as number types, while WASM has integers and floats)
nfriedly 9y ago
WebAssembly is (currently) the same as asm.js, but with smaller file size and faster parse times. Asm.js is just a subset of JavaScript that can be optimized because it doesn't use certain features (like strings or garbage collection). WebAssembly and asm.js are both intended to be compile targets - you don't write them by hand, but instead write your code in another language (c, Rust, etc.) and then complie to them. The main benefits are 1) JavaScript is no longer the only language of the web, and 2) it's possible to get better performance than JS ever allowed for. There is a lot of c code out there that probably isn't worth rewriting fron scratch in JS, but may well be worth recompiling to run as a web app. Also, in the future, WebAssembly should get DOM access, optional garbage collection and other features that will allow it to be a compile targets for other languages such as Python and Ruby. So then you can use a single language for all of your development without that language being JavaScript.

by fergie 9y ago

SirHound 9y ago

I can address at least the first misconception here - this isn’t transpilation to JS. This is native code that has browser APIs exposed to it, so in theory there should be massive performance wins.

poizan42 9y ago
This is also a misconception, it is just a bytecode. asm.js is already running at around 50% native speed so there is no massive performance wins to find. What you get with WebAssembly is reduced startup time because it doesn't have to be parsed first. The really exciting thing people should be talking about is not WebAssembly but the general availability of SharedArrayBuffer[0] which finally makes it possible to run "foreign" multi-threaded code efficiently. [0]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

exDM69 9y ago

WASM is used to run native code in the Web browser without going through JavaScript. With it, it should be possible to run code at near-native performance in the browser. WASM is an intermediate representation which is output by your compiler (of your favorite language) and consumed by the browser's compiler to emit native code. WASM is a bit similar to LLVM IR, but it's architecture independent. Compare this to, say, LLVM and Clang. Clang (the C compiler front end) will read C code and emit LLVM IR. LLVM (the compiler backend) will read LLVM IR and emit assembly code for your CPU. With WASM, the developer will run the "front end" and distribute the WASM code over HTTP and the web browser will run the backend and turn WASM into native assembly code. > I get that its a clever way of transpiling existing programs to JavasScript, but surely we could do that already? No, WASM code is not JavaScript at any point. ASM.js is a predecessor to WASM that was a compiler-friendly variant of JavaScript that can be compiled to native code.

fergie 9y ago
Oh I see- that makes sense.
qaq 9y ago
But is this how it is implemented by actual browsers? if memory serves v8 is pretty much reusing most of JS VM for WASM?
- exDM69 9y ago
  Yes, the browsers do share parts of their JavaScript execution engine with WASM. Which makes sense because WASM still needs to interact with JS. That doesn't mean it can't be fast or start quickly (or at least quicker than asm.js). From the developer's point of view that doesn't matter. You're delivering WASM and not C or JS code over to the clients.
- marcosdumay 9y ago
  WASM requires a much simpler VM than JS. It doesn't take most of a JS VM.

steveklabnik 9y ago

WebAssembly is a specification of a small assembly language. This language can call into functions in its host environment. The "web" part is that all evergreen web browsers have implemented this language, and you can use it from inside your browser, and call JavaScript functions into it. This means that WebAssembly is actually broader than just the web; for example the Etherium folks have been discussing using wasm as their language to script their blockchain. It doesn't currently open up any real new API hooks; it's mostly about being an efficient language for computation. You get near-native performance in the browser. In the future, it may or may not grow more hooks directly into the web platform, rather than needing to call into JS to do so.

Fredx87 9y ago

Today the browsers virtual machines can work only with Javascript code. That means that if you want to use another language you have to convert in to Javascript, and you are obviously limited by the features of Javascript. The goal of WASM is to provide a language similar to Assembly (or bytecode of Java) that can be understood by the virtual machines of browser, and so to have a new way to compile languages and use them in the browsers. WASM can also be optimized better, having more features than Javascript (for example javascript uses only double as number types, while WASM has integers and floats)

nfriedly 9y ago

WebAssembly is (currently) the same as asm.js, but with smaller file size and faster parse times. Asm.js is just a subset of JavaScript that can be optimized because it doesn't use certain features (like strings or garbage collection). WebAssembly and asm.js are both intended to be compile targets - you don't write them by hand, but instead write your code in another language (c, Rust, etc.) and then complie to them. The main benefits are 1) JavaScript is no longer the only language of the web, and 2) it's possible to get better performance than JS ever allowed for. There is a lot of c code out there that probably isn't worth rewriting fron scratch in JS, but may well be worth recompiling to run as a web app. Also, in the future, WebAssembly should get DOM access, optional garbage collection and other features that will allow it to be a compile targets for other languages such as Python and Ruby. So then you can use a single language for all of your development without that language being JavaScript.