Hacker News Reader

Comment by tomdale | Hacker News Reader

WebAssembly doesn't give you access to DOM APIs, so it's not like you could rewrite Angular in wasm, for example. Most load time/parse time discussions are in the context of web frameworks, but they're typically not able to benefit from the performance improvements of WebAssembly, particularly given the overhead of moving data into and out of the wasm context.

View on HN

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

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.

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.

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.

Not first class access, but you can call arbitrary JavaScript via FFI. An approach that worked fine for me was to use a simple object which holds your DOM handles via incrementing numeric IDs and pass them back to your Rust (or C++) code. I found the FFI overhead to be non-existent compared to the actual DOM work as well.

> a simple object which holds your DOM handles via incrementing numeric IDs and pass them back to your Rust (or C++) code.

How do you know when to release those handles so the GC can clean them up?

In my case I knew when the owning Rust struct was destroyed, and it was guaranteed to be the only thing holding the element handle so I would just free the DOM node during the destruction logic.

For something more general purpose I'd probably just use a destructor (whether C++ or Rust) with the same guarantee of single-ownership of the underlying ID, and the DOM node will automatically be freed once the native handle goes out of scope.

Edit: Of course, you'd have to prohibit copies on the native side.

Well such object references and also string handling (not first-class representation in asm.js/current-wasm either) is just a lot of pointer munging really --- realistically I don't see many of today's framework writers re-expressing their visions at that level, plus in the browser context you need them to be "safe pointers"/"references" managed carefully etc.. can of worms. wasm/asm.js' prime use cases are certainly in high loads of real-time numerical calculations, I'm not just talking games or shader-helpers (and sciency/other simulations whether in academia or commercial solutions) but also envisioning faster, neater in-browser apps evolving for all sorts of media (pics/vids/audio/360°/etc) handling/editing/munging etc.

Reply on news.ycombinator.com