3 ms·

[1] https://auth0.com/blog/7-things-you-should-know-about-web-assembly/ https://auth0.com/blog/7-things-you-should-know-about-web-as... [2] https://gotechster.

[1] https://auth0.com/blog/7-things-you-should-know-about-web-assembly/ https://auth0.com/blog/7-things-you-should-know-about-web-as... [2] https://gotechster.com/2017/04/web-assembly/ https://gotechster.com/2017/04/web-assembly/ [3] http://webassembly.org/docs/use-cases/ http://webassembly.org/docs/use-cases/ The last one is from WASM official site. Nobody will write directly in WASM just like nobody writes Assembly directly for complex stuff. Also the entire thing is officially supported now in Firefox and Chrome with Edge and safari soon to support. (P.S I am not a web developer and most of my info is from other people so I maybe wrong. If I am do tell me) About the DOM, see this [4] http://webassembly.org/docs/gc/ http://webassembly.org/docs/gc/ DOM, GC are future goals.

munificent 9y ago
GC has been a future goal since mid-2015 [1]. At some point in the future when (if?) that's supported then WASM may become a better target for compilers than JS is today. Until then, I don't see WASM as super compelling. Think of it like this: WASM is effectively a subset of JS. If you're compiling to run in a browser, by targeting that subset, you don't get to use any of the features outside of that subset that browsers already have high performance, battle-tested implementations of. Worse, you then have to reimplement those features yourself and ship them down with the application. [1]: https://github.com/WebAssembly/design/commit/b2ea1983c0c0e9e03df96df0edc7e18beedd8229 https://github.com/WebAssembly/design/commit/b2ea1983c0c0e9e...