Hacker News Reader

Comment by stupidcar | Hacker News Reader

Access to DOM APIs isn't part of the MVP, but it is listed as a high-level goal[1] and is specced as a future feature[2].

[1] https://github.com/WebAssembly/design/blob/master/HighLevelG... [2] https://github.com/WebAssembly/design/blob/master/GC.md

View on HN

I'm excited for this and eagerly look forward to adopting it in Ember as soon as it's mature, but I'm guessing this is still at least a few years out.

Even when it's out and mature, there is some complexity around gracefully degrading when it is not available - it is going to increase frontend complexity dramatically I suspect, at least until browser support dictates that graceful fallback isn't necessary for the feature.

Most current WebAssembly compilation paths produce asm.js as an intermediate artifact. In the near term, backwards compatibility should be relatively simple: save both and load the asm.js code as a fallback.

Or you can do it on the client side by hooking into the module loader and decompiling the wasm back into asm.js. See for example the

https://github.com/lukewagner/polyfill-prototype-1

PoC mentioned in the wasm FAQ.

Perhaps, but I've been surprised at how fast WASM support has moved already, and how committed all the browser vendors has been. Usually there's at least hold-out.

I feel like there may be enough internal pressure from groups in Apple, Google and Microsoft to get DOM integration available, so that they can experiment with compiling the likes of Swift, Dart and C# to it, that it will become a priority once the MVP has shipped.

Reply on news.ycombinator.com