5 ms·

I'll be excited about WebAssembly when it can manipulate DOM. Until then, it feels mostly like a thought experiment in that the number of people that it makes s

I'll be excited about WebAssembly when it can manipulate DOM. Until then, it feels mostly like a thought experiment in that the number of people that it makes sense to use right now is miniscule.

chinedufn 8y ago
Check out Rust’s wasm-bindgen - https://github.com/rustwasm/wasm-bindgen https://github.com/rustwasm/wasm-bindgen if ya haven’t already. Right now it you call into JS to interact with the DOM but when the host bindings proposal sees fruit it’ll replace the JS shims with direct DOM manipulation!
- seanmcdirmid 8y ago
  It isn’t clear how they will allow safe access to the DOM without GC. Maybe they’ll take an approach like Microsoft did with UWP and use reference counting?
  - tjallingt 8y ago
    Would be interesting if it would be possible to take the Rust approach and guarantee at parse/compilation time that the DOM interactions are safe without runtime overhead. Probably a terrible idea for mobile devices though...
    - seanmcdirmid 8y ago
      That would only work if it isn’t shared with unsafe code.
rudedogg 8y ago
Same, I started looking into WASM yesterday, and was disappointed to find out you can't do DOM manipulation as that was my use case. From my brief research https://github.com/WebAssembly/host-bindings https://github.com/WebAssembly/host-bindings is the repository to watch for progress.
vardump 8y ago
The possibility of WebAssembly becoming tangled with complicated web browsers worries me. Whatever DOM manipulation there may be in the future, I hope there'll be no tight coupling with DOM, GC or anything else. If tight coupling can be avoided, WebAssembly could become lingua franca of binary formats also outside web. For things like architecture agnostic plugins, extensions and high performance light weight "scripting" support.
- DonHopkins 8y ago
  I think the point is to integrate WebAssembly with JavaScript objects in general, not the DOM API in particular. Nothing to do with web browsers, everything to do with JavaScript.
- steveklabnik 8y ago
  It's called the "host bindings" proposal because the proposal is to create bindings to the host environemnt; for a browser that's the DOM, for for any other host, it could be other things. It's not tightly coupled to them.
  - vardump 8y ago
    > It's not tightly coupled to them. Hopefully it'll stay that way. Dependencies on DOM or Javascript would be devastating for WebAssembly use outside web browsers.
    - steveklabnik 8y ago
      Everyone[1] who works on wasm cares about the non-browser use-case, so I think you can sleep easy here. 1: Okay so, what I really mean is, "I spend a lot of time talking to people working on WebAssembly and they've all expressed that to me but of course I hvaen't talked to literally every single last person".
kuwze 8y ago
Why would you want to do that? DOM manipulation is what makes JS slow, not JS itself.

I'll be excited about WebAssembly when it can manipulate DOM. Until then, it feels mostly like a thought experiment in that the number of people that it makes sense to use right now is miniscule.

chinedufn 8y ago

Check out Rust’s wasm-bindgen - https://github.com/rustwasm/wasm-bindgen https://github.com/rustwasm/wasm-bindgen if ya haven’t already. Right now it you call into JS to interact with the DOM but when the host bindings proposal sees fruit it’ll replace the JS shims with direct DOM manipulation!

seanmcdirmid 8y ago
It isn’t clear how they will allow safe access to the DOM without GC. Maybe they’ll take an approach like Microsoft did with UWP and use reference counting?
- tjallingt 8y ago
  Would be interesting if it would be possible to take the Rust approach and guarantee at parse/compilation time that the DOM interactions are safe without runtime overhead. Probably a terrible idea for mobile devices though...
  - seanmcdirmid 8y ago
    That would only work if it isn’t shared with unsafe code.

rudedogg 8y ago

Same, I started looking into WASM yesterday, and was disappointed to find out you can't do DOM manipulation as that was my use case. From my brief research https://github.com/WebAssembly/host-bindings https://github.com/WebAssembly/host-bindings is the repository to watch for progress.

vardump 8y ago

The possibility of WebAssembly becoming tangled with complicated web browsers worries me. Whatever DOM manipulation there may be in the future, I hope there'll be no tight coupling with DOM, GC or anything else. If tight coupling can be avoided, WebAssembly could become lingua franca of binary formats also outside web. For things like architecture agnostic plugins, extensions and high performance light weight "scripting" support.

DonHopkins 8y ago
I think the point is to integrate WebAssembly with JavaScript objects in general, not the DOM API in particular. Nothing to do with web browsers, everything to do with JavaScript.
steveklabnik 8y ago
It's called the "host bindings" proposal because the proposal is to create bindings to the host environemnt; for a browser that's the DOM, for for any other host, it could be other things. It's not tightly coupled to them.
- vardump 8y ago
  > It's not tightly coupled to them. Hopefully it'll stay that way. Dependencies on DOM or Javascript would be devastating for WebAssembly use outside web browsers.
  - steveklabnik 8y ago
    Everyone[1] who works on wasm cares about the non-browser use-case, so I think you can sleep easy here. 1: Okay so, what I really mean is, "I spend a lot of time talking to people working on WebAssembly and they've all expressed that to me but of course I hvaen't talked to literally every single last person".

kuwze 8y ago

Why would you want to do that? DOM manipulation is what makes JS slow, not JS itself.