4 ms·

I think WebAssembly has a huge expectations problem: What many people think it is: I can compile my JS frameworks as assembly and ship binaries to the browser,

by atonse 9y ago

I think WebAssembly has a huge expectations problem: What many people think it is: I can compile my JS frameworks as assembly and ship binaries to the browser, that'll run near-native and be more compact. What WebAssembly actually is: a way to compile libraries from other languages in a manner that you can run them in a JS runtime, but with no access to the DOM, etc. (Think of things like shipping a JS based OCR library or a JS based audio-engine that runs at near-native speeds)

floatboth 9y ago
Yeah. I don't understand why people want this, or why people think it will bring huge performance gains… but someday in the future wasm will get direct DOM access. (And right now it's possible by exposing JS functions to wasm.)
grondilu 9y ago
> but with no access to the DOM There will be access to the DOM, but even without it, WebAssembly is still useful. You compile libraries that are performance sensitive, you use them from you JS code, and voilà, you have the best of both words : the flexibility and DOM access with JS, and the speed of compiled code with wasm.
- atonse 9y ago
  Good point – I didn't it wasn't useful, just that there are a lot of people who think that you will be compiling React.js or jQuery as-is to WebAssembly, and just shipping them that way. That's just not how it'll work.
tannhaeuser 9y ago
Thanks for putting the discussion back into the realm of reality. For as long as I'm in IT, there has always been the story of an upcoming holy grail of technology that'll change everything aka the silver bullet. Reading through this thread, that role seems currently occupied by WASM, with wild projections of all kind of perceived problems of frontend development and beyond onto WASM. The reality is I have yet to see a single app making use of WASM on the web. And even when, if, there eventually is a WASM app, it won't be able to do anything that other (native) development environments haven't been able to do for ages. I'm not sure the world needs a new bytecode format, when only the ARM and x86_64 ISAs are still around. OTOH, what's new with WASM is that the browser and the internet acts as a gatekeeper for starting apps on your device, which I'm not sure will be met with enthusiasm by users. Furthermore, since WASM lacks APIs for even the most basic things, it would take ages to establish a platform, with all the fragmentation this entails.
- grondilu 9y ago
  > The reality is I have yet to see a single app making use of WASM on the web. IMHO a spectacular example is stockfish on lichess.org. On some browsers, like Chrome and Firefox IIRC, it is still slower than PNACL or asm.js, but on Microsoft Edge it is the fastest solution and it's what is currently used for this browser. It should be the fastest solution everywhere once multithreading is added. The developer of lichess stated that is was fairly trivial to port stockfish to webassembly and compile it for lichess. When I saw it running, I was impressed (and still am).
jules 9y ago
WebAssembly is not just about compiling libraries to access them from JS. WebAssembly is about compiling other languages to be able to run on the web with reasonable speed. WebAssembly programs will have access to the DOM.

by atonse 9y ago

floatboth 9y ago

Yeah. I don't understand why people want this, or why people think it will bring huge performance gains… but someday in the future wasm will get direct DOM access. (And right now it's possible by exposing JS functions to wasm.)

grondilu 9y ago

> but with no access to the DOM There will be access to the DOM, but even without it, WebAssembly is still useful. You compile libraries that are performance sensitive, you use them from you JS code, and voilà, you have the best of both words : the flexibility and DOM access with JS, and the speed of compiled code with wasm.

atonse 9y ago
Good point – I didn't it wasn't useful, just that there are a lot of people who think that you will be compiling React.js or jQuery as-is to WebAssembly, and just shipping them that way. That's just not how it'll work.

tannhaeuser 9y ago

Thanks for putting the discussion back into the realm of reality. For as long as I'm in IT, there has always been the story of an upcoming holy grail of technology that'll change everything aka the silver bullet. Reading through this thread, that role seems currently occupied by WASM, with wild projections of all kind of perceived problems of frontend development and beyond onto WASM. The reality is I have yet to see a single app making use of WASM on the web. And even when, if, there eventually is a WASM app, it won't be able to do anything that other (native) development environments haven't been able to do for ages. I'm not sure the world needs a new bytecode format, when only the ARM and x86_64 ISAs are still around. OTOH, what's new with WASM is that the browser and the internet acts as a gatekeeper for starting apps on your device, which I'm not sure will be met with enthusiasm by users. Furthermore, since WASM lacks APIs for even the most basic things, it would take ages to establish a platform, with all the fragmentation this entails.

grondilu 9y ago
> The reality is I have yet to see a single app making use of WASM on the web. IMHO a spectacular example is stockfish on lichess.org. On some browsers, like Chrome and Firefox IIRC, it is still slower than PNACL or asm.js, but on Microsoft Edge it is the fastest solution and it's what is currently used for this browser. It should be the fastest solution everywhere once multithreading is added. The developer of lichess stated that is was fairly trivial to port stockfish to webassembly and compile it for lichess. When I saw it running, I was impressed (and still am).

jules 9y ago

WebAssembly is not just about compiling libraries to access them from JS. WebAssembly is about compiling other languages to be able to run on the web with reasonable speed. WebAssembly programs will have access to the DOM.