4 ms·

>> One big 2018 goal for the Rust community is to become a web language. Without DOM access I fail to see how that would happen. So until WASM gets DOM access

>> One big 2018 goal for the Rust community is to become a web language. Without DOM access I fail to see how that would happen. So until WASM gets DOM access no other language(except JS) can become a(first class) web language. What is JavaScript without DOM access?

steveklabnik 9y ago
You can access the DOM, but you have to call into JS, which adds some overhead. When people say “DOM access,” they mean native, not through JS. Check out the stdweb crate. Even then, there's tons of logic you want to execute in the browser that aren't related to UI. For example, any sort of number crunching. That stuff is now feasible, which opens up all kinds of applications.
- TomasSedovic 9y ago
  To add a specific example here, I've recently compiled a roguelike I'm working on to WASM, not knowing what to expect when I started. This required only a handful of changes across the codebase (mostly handling external resources such as the filesystem and the random generator) and then implementing a bit of JavaScript that took the drawcalls from the WASM core and rendered them on the canvas. And vice-versa, a bit of JS that passed the browser input into the WASM game. Since the original game had no concept of a DOM, it didn't matter to it. I think WASM can be huge for browser games. But like Steve said, you can call any JavaScript function and manipulate the DOM that way. At least for Rust, there's also a library that does this for you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge is handled for you: https://github.com/koute/stdweb https://github.com/koute/stdweb
  - seanmcdirmid 9y ago
    Does WASM provide a canvas API at least (i.e. something more advanced than pushing pixels to a buffer)?
    - steveklabnik 9y ago
      Nope, you call into JS for that as well. Canvas, WebGL, whatever.
  - tyingq 9y ago
    The bridge is currently VERY slow though. Like 10x slower than doing it in JS, sometimes worse.
    - zaarn 9y ago
      Then applications in WASM will have to reduce the number of these calls until it gets native. This can be easily achieved by buffering calls to the DOM and merging batches of actions together (you could probably even divide DOM actions into priority queues to improve reaction time at expense of throughput in less important UI elements)
      - imtringued 9y ago
        I'm wondering if it would make sense to have a virtual DOM inspired by react. This would be faster than direct DOM access via a bridge.
        zaarn 9y ago
        A vastly simplified DOM if anything. I imagine each language will use native objects, like how .NET did it for a while. But I don't think languages will interact with the DOM extensively once it has been properly abstracted. One major difficulty would be to have it available quickly so a page refresh doesn't take until the WASM binary has sorted out it's internal state.
- kllrnohj 9y ago
  > For example, any sort of number crunching. That stuff is now feasible, which opens up all kinds of applications. Not really. You're still hamstrung by either being single threaded & time sliced with the UI thread (huzzah for cooperative multitasking still somehow not being dead), or you need to jump through the webworkers hoop if you're lucky enough to have a problem & dataset that's compatible with webworker's rather severe limitations. webasm claims to have threading support on the roadmap but until that happens anything truly involving heavy number crunching is still largely infeasible. And with SharedArrayBuffer being killed by spectre there's a lot of rather major unknowns to deal with.
  - steveklabnik 9y ago
    Sure, there’s always more work to do.
geofft 9y ago
I'm not sure if this quite counts as "web" (especially because of accessibility barriers), but I can totally see a future where people frustrated with CSS and the DOM just render their web page with a completely alternative UI toolkit on top of a giant <canvas>.
mshenfield 9y ago
Virtual DOM springs to mind. React/Vue.js/Ember all implement a lightweight fascimile of the DOM used to do support DOM diffing, which that could be ported to WASM. Here's an example of someone who has written one already: https://github.com/mbasso/asm-dom https://github.com/mbasso/asm-dom
- steveklabnik 9y ago
  https://github.com/glimmerjs/glimmer-vm/pull/752 https://github.com/glimmerjs/glimmer-vm/pull/752

steveklabnik 9y ago

You can access the DOM, but you have to call into JS, which adds some overhead. When people say “DOM access,” they mean native, not through JS. Check out the stdweb crate. Even then, there's tons of logic you want to execute in the browser that aren't related to UI. For example, any sort of number crunching. That stuff is now feasible, which opens up all kinds of applications.

TomasSedovic 9y ago
To add a specific example here, I've recently compiled a roguelike I'm working on to WASM, not knowing what to expect when I started. This required only a handful of changes across the codebase (mostly handling external resources such as the filesystem and the random generator) and then implementing a bit of JavaScript that took the drawcalls from the WASM core and rendered them on the canvas. And vice-versa, a bit of JS that passed the browser input into the WASM game. Since the original game had no concept of a DOM, it didn't matter to it. I think WASM can be huge for browser games. But like Steve said, you can call any JavaScript function and manipulate the DOM that way. At least for Rust, there's also a library that does this for you. So you can have Rust code that uses a DOM API and the WASM <-> JS bridge is handled for you: https://github.com/koute/stdweb https://github.com/koute/stdweb
- seanmcdirmid 9y ago
  Does WASM provide a canvas API at least (i.e. something more advanced than pushing pixels to a buffer)?
  - steveklabnik 9y ago
    Nope, you call into JS for that as well. Canvas, WebGL, whatever.
- tyingq 9y ago
  The bridge is currently VERY slow though. Like 10x slower than doing it in JS, sometimes worse.
  - zaarn 9y ago
    Then applications in WASM will have to reduce the number of these calls until it gets native. This can be easily achieved by buffering calls to the DOM and merging batches of actions together (you could probably even divide DOM actions into priority queues to improve reaction time at expense of throughput in less important UI elements)
    - imtringued 9y ago
      I'm wondering if it would make sense to have a virtual DOM inspired by react. This would be faster than direct DOM access via a bridge.
      - zaarn 9y ago
        A vastly simplified DOM if anything. I imagine each language will use native objects, like how .NET did it for a while. But I don't think languages will interact with the DOM extensively once it has been properly abstracted. One major difficulty would be to have it available quickly so a page refresh doesn't take until the WASM binary has sorted out it's internal state.
kllrnohj 9y ago
> For example, any sort of number crunching. That stuff is now feasible, which opens up all kinds of applications. Not really. You're still hamstrung by either being single threaded & time sliced with the UI thread (huzzah for cooperative multitasking still somehow not being dead), or you need to jump through the webworkers hoop if you're lucky enough to have a problem & dataset that's compatible with webworker's rather severe limitations. webasm claims to have threading support on the roadmap but until that happens anything truly involving heavy number crunching is still largely infeasible. And with SharedArrayBuffer being killed by spectre there's a lot of rather major unknowns to deal with.
- steveklabnik 9y ago
  Sure, there’s always more work to do.

geofft 9y ago

I'm not sure if this quite counts as "web" (especially because of accessibility barriers), but I can totally see a future where people frustrated with CSS and the DOM just render their web page with a completely alternative UI toolkit on top of a giant <canvas>.

mshenfield 9y ago

Virtual DOM springs to mind. React/Vue.js/Ember all implement a lightweight fascimile of the DOM used to do support DOM diffing, which that could be ported to WASM. Here's an example of someone who has written one already: https://github.com/mbasso/asm-dom https://github.com/mbasso/asm-dom

steveklabnik 9y ago
https://github.com/glimmerjs/glimmer-vm/pull/752 https://github.com/glimmerjs/glimmer-vm/pull/752