6 ms·

You can write a WASM program today that touches the DOM, it just needs to go through the regular JS APIs. While there were some discussions early on about makin

You can write a WASM program today that touches the DOM, it just needs to go through the regular JS APIs. While there were some discussions early on about making custom APIs for WASM to access, that has long since been dropped - there are just too many downsides.

cedws 1y ago
But then you need two things instead of one. It should be made possible to build WASM-only SPAs. The north star of browser developers should be to deprecate JS runtimes the same way they did Flash.
- bonestamp2 1y ago
  I agree with the first part, but getting rid of JS entirely means that if you want to augment some HTML with one line of javascript you have to build a WASM binary to do it? I see good use cases for building entirely in html/JS and also building entirely in WASM.
  - em-bee 1y ago
    getting rid of javascript entirely means to be able to manipulate the DOM without writing any javascript code. not to remove javascript from the browser. javascript will still be there if you want to use it.
    - catlifeonmars 1y ago
      Most of the time your toolchain provides a shim so you don’t need to write JS anyway. What’s the difference?
      - em-bee 1y ago
        right, that's exactly the point. those that have a shim already successfully got rid of javascript, and that's enough.
    - bonestamp2 1y ago
      Fair enough, I misunderstood what he meant by "deprecate JS runtimes".
- brokencode 1y ago
  You can use a framework that abstracts all the WASM to JS communication for DOM access. There are many such framework already. The only issue is that there’s a performance cost. Not sure how significant it is for typical applications, but it definitely exists. It’d be nice to have direct DOM access, but if the performance is not a significant problem, then I can see the rationale for not putting in the major amount of work work it’d take to do this.
  - saulpw 1y ago
    Which framework is the best or most commonly used?
    - tracker1 1y ago
      Yew, Leptos and Dioxus are all pretty decent with their own advantages and disadvantages if you like Rust. It's been a year or so since I last looked at them, to me the biggest missing piece was a component library along the lines of MUI to build useful things with. I'd be surprised if there weren't at least Bootstrap compatible wrapper libraries for them at this point.
- austin-cheney 1y ago
  That is never going to happen until you create your own browser with a fork of the WASM spec. People have been asking for this for about a decade. The WASM team knows this but WASM wants to focus on its mission of being a universal compile target without distraction of the completely unrelated mission of being a JavaScript replacement.
  - spartanatreyu 1y ago
    It's also too early to worry about DOM apis over wasm instead of js. The whole problem with the DOM is that it has too many methods which can't be phased out without losing backwards compatibility. A new DOM wasm api would be better off starting with a reduced API of only the good data and operations. The problem is that the DOM is still improving (even today), it's not stabilized so we don't have that reduced set to draw from, and if you were to mark a line in the sand and say this is our reduced set, it would already not be what developers want within a year or two. New DOM stuff is coming out all the time, even right now we two features coming out that can completely change the way that developers could want to build applications: - being able to move dom nodes without having to destroy and recreate them. This makes it possible so you can keep the state inside that dom node unaffected, such as a video playing without having to unload and reload a video. Now imagine if that state can be kept over the threshold of a multi-page view transition. - the improved attr() api which can move a lot of an app's complexity from the imperative side to the declarative side. Imagine a single css file that allows html content creators to dictate their own grid layouts, without needing to calculate every possible grid layout at build time. And just in the near future things are moving to allow html modules which could be used with new web component apis to prevent the need for frameworks in large applications. Also language features can inform API design. Promises were added to JS after a bunch of DOM APIs were already written, and now promises can be abortable. Wouldn't we want the new reduced API set to also be built upon abortable promises? Yes we would. But if we wait a bit longer, we could also take advantage of newer language features being worked on in JS like structs and deeply immutable data structures. TL;DR: It's still too early to work on a DOM api for wasm. It's better to wait for the DOM to stabalize first.
    - 1y ago
zekrioca 1y ago
Could you list some of these downsides and what are the reason of their existence?
- cogman10 1y ago
  For starters, the DOM API is huge and expansive. Simply giving WASM the DOM means you are greatly expanding what the sandbox can do. That means lower friction when writing WASM with much much higher security risks. But further, WASM is more than just a browser thing at this point. You might be running in an environment that has no DOM to speak of (think nodejs). Having this bolted on extension simply for ease of use means you now need to decide how and when you communicate its availability. And the benefits just aren't there. You can create a DOM exposing library for WASM if you really want to (I believe a few already exist) but you end up with a "what's the point". If you are trying to make some sort of UX framework based on wasm then you probably don't want to actually expose the DOM, you want to expose the framework functions.
  - mycall 1y ago
    > you probably don't want to actually expose the DOM, you want to expose the framework functions. Aren't the framework functions closely related to the DOM properties and functions?
colordrops 1y ago
Isn't going through the JS APIs slow?
- nasso_dev 1y ago
  used to be, in the early days, but nowadays runtimes optimized the function call overhead between WASM and JS to near zero https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
  - lukan 1y ago
    It did improved a lot, but unfortunately not near zero enough. It is managable if you avoid js wasm round trips, but if you assume the cost is near zero you will be in for a unpleasant surprise. When I have to do a lot of different calls into my wasm blob, I am way way faster batching them. Meaning making one cal into wasm, that then gets all the data I want and returns it.
lyu07282 1y ago
I was under the impression that this very much still on the table, with active work like the component model laying the foundation for the ABI to come.
benrutter 1y ago
I have slightly different question than OP - what's left until it feels like javascript is gone for people who don't want to touch it? Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again?
- tcfhgj 1y ago
  > Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again? yes, e.g. with Leptos you don't have to touch JS at all

cedws 1y ago

But then you need two things instead of one. It should be made possible to build WASM-only SPAs. The north star of browser developers should be to deprecate JS runtimes the same way they did Flash.

bonestamp2 1y ago
I agree with the first part, but getting rid of JS entirely means that if you want to augment some HTML with one line of javascript you have to build a WASM binary to do it? I see good use cases for building entirely in html/JS and also building entirely in WASM.
- em-bee 1y ago
  getting rid of javascript entirely means to be able to manipulate the DOM without writing any javascript code. not to remove javascript from the browser. javascript will still be there if you want to use it.
  - catlifeonmars 1y ago
    Most of the time your toolchain provides a shim so you don’t need to write JS anyway. What’s the difference?
    - em-bee 1y ago
      right, that's exactly the point. those that have a shim already successfully got rid of javascript, and that's enough.
  - bonestamp2 1y ago
    Fair enough, I misunderstood what he meant by "deprecate JS runtimes".
brokencode 1y ago
You can use a framework that abstracts all the WASM to JS communication for DOM access. There are many such framework already. The only issue is that there’s a performance cost. Not sure how significant it is for typical applications, but it definitely exists. It’d be nice to have direct DOM access, but if the performance is not a significant problem, then I can see the rationale for not putting in the major amount of work work it’d take to do this.
- saulpw 1y ago
  Which framework is the best or most commonly used?
  - tracker1 1y ago
    Yew, Leptos and Dioxus are all pretty decent with their own advantages and disadvantages if you like Rust. It's been a year or so since I last looked at them, to me the biggest missing piece was a component library along the lines of MUI to build useful things with. I'd be surprised if there weren't at least Bootstrap compatible wrapper libraries for them at this point.
austin-cheney 1y ago
That is never going to happen until you create your own browser with a fork of the WASM spec. People have been asking for this for about a decade. The WASM team knows this but WASM wants to focus on its mission of being a universal compile target without distraction of the completely unrelated mission of being a JavaScript replacement.
- spartanatreyu 1y ago
  It's also too early to worry about DOM apis over wasm instead of js. The whole problem with the DOM is that it has too many methods which can't be phased out without losing backwards compatibility. A new DOM wasm api would be better off starting with a reduced API of only the good data and operations. The problem is that the DOM is still improving (even today), it's not stabilized so we don't have that reduced set to draw from, and if you were to mark a line in the sand and say this is our reduced set, it would already not be what developers want within a year or two. New DOM stuff is coming out all the time, even right now we two features coming out that can completely change the way that developers could want to build applications: - being able to move dom nodes without having to destroy and recreate them. This makes it possible so you can keep the state inside that dom node unaffected, such as a video playing without having to unload and reload a video. Now imagine if that state can be kept over the threshold of a multi-page view transition. - the improved attr() api which can move a lot of an app's complexity from the imperative side to the declarative side. Imagine a single css file that allows html content creators to dictate their own grid layouts, without needing to calculate every possible grid layout at build time. And just in the near future things are moving to allow html modules which could be used with new web component apis to prevent the need for frameworks in large applications. Also language features can inform API design. Promises were added to JS after a bunch of DOM APIs were already written, and now promises can be abortable. Wouldn't we want the new reduced API set to also be built upon abortable promises? Yes we would. But if we wait a bit longer, we could also take advantage of newer language features being worked on in JS like structs and deeply immutable data structures. TL;DR: It's still too early to work on a DOM api for wasm. It's better to wait for the DOM to stabalize first.
  - 1y ago

zekrioca 1y ago

Could you list some of these downsides and what are the reason of their existence?

cogman10 1y ago
For starters, the DOM API is huge and expansive. Simply giving WASM the DOM means you are greatly expanding what the sandbox can do. That means lower friction when writing WASM with much much higher security risks. But further, WASM is more than just a browser thing at this point. You might be running in an environment that has no DOM to speak of (think nodejs). Having this bolted on extension simply for ease of use means you now need to decide how and when you communicate its availability. And the benefits just aren't there. You can create a DOM exposing library for WASM if you really want to (I believe a few already exist) but you end up with a "what's the point". If you are trying to make some sort of UX framework based on wasm then you probably don't want to actually expose the DOM, you want to expose the framework functions.
- mycall 1y ago
  > you probably don't want to actually expose the DOM, you want to expose the framework functions. Aren't the framework functions closely related to the DOM properties and functions?

colordrops 1y ago

Isn't going through the JS APIs slow?

nasso_dev 1y ago
used to be, in the early days, but nowadays runtimes optimized the function call overhead between WASM and JS to near zero https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%F0%9F%8E%89/ https://hacks.mozilla.org/2018/10/calls-between-javascript-a...
- lukan 1y ago
  It did improved a lot, but unfortunately not near zero enough. It is managable if you avoid js wasm round trips, but if you assume the cost is near zero you will be in for a unpleasant surprise. When I have to do a lot of different calls into my wasm blob, I am way way faster batching them. Meaning making one cal into wasm, that then gets all the data I want and returns it.

lyu07282 1y ago

I was under the impression that this very much still on the table, with active work like the component model laying the foundation for the ABI to come.

benrutter 1y ago

I have slightly different question than OP - what's left until it feels like javascript is gone for people who don't want to touch it? Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again?

tcfhgj 1y ago
> Say I really want to write front end code in Rust* does there just need to be a library that handles the js DOM calls for me? After that, I don't ever have to think about javascript again? yes, e.g. with Leptos you don't have to touch JS at all