4 ms·

> Wasm makes it thinkable to do DOM programming in languages other than JavaScript Does it really? AFAIK, if I want to do any kind of DOM manipulation in say,

> Wasm makes it thinkable to do DOM programming in languages other than JavaScript Does it really? AFAIK, if I want to do any kind of DOM manipulation in say, rust, I need bindings that will basically serialize calls to be done on the JS side. So with the current incarnation of wasm, I believe you're still stuck with JS.

yencabulator 2y ago
As far as I understand: The intent of WASI is to provide (among other things) a direct to DOM API. One where e.g. a DOM implemented in Rust can be used from a WASM module written in Rust without executing any Javascript. Some of that gets fiddly because the DOM API is sort of specified with Javascript semantics.. so they're going for things with less Javascript legacy baggage first, like HTTP requests (server & client), TCP sockets, filesystem access.
__s 2y ago
Important to include the preceding "With GC," In theory you can import DOM functions from runtime & call with references to dom objects now, bypassing JS to call directly into runtime (I say in theory because I'm not in the know whether this is actually possible, but GC at least brings prerequisite mechanisms to get to that point)
- posix86 2y ago
  How does GC help with that?
  - __s 2y ago
    GC feature in wasm extends to having opaque references outside linear memory (which may reference objects controlled by host system's gc) avoiding need for js caller to handle resource being freed by wasm code with a pool or something keyed by handles (integers) passed to wasm
  - SpaghettiCthulu 2y ago
    I think it would enable WASM code to hold references to DOM objects that have been designed around garbage collection.
josephg 2y ago
I've been playing around with leptos for rust lately - which is a super fast framework for doing web frontend work with rust via wasm. It seems fine, honestly. Basically the same as solidjs: #[component] fn App() -> impl IntoView { let (count, set_count) = create_signal(0); view! { <button on:click=move |_| { set_count(3); }> "Click me: "{move || count()} </button> } } There's some extra size overhead from wasm compared to javascript, but its honestly not that bad. After wasm-opt and brotli compression, the wasm bundle for this counter app is 37kb. So its in the same general ballpark as react, but much faster once its up and running. I haven't tried doing direct DOM manipulation with it. But for general components it seems great.

yencabulator 2y ago

As far as I understand: The intent of WASI is to provide (among other things) a direct to DOM API. One where e.g. a DOM implemented in Rust can be used from a WASM module written in Rust without executing any Javascript. Some of that gets fiddly because the DOM API is sort of specified with Javascript semantics.. so they're going for things with less Javascript legacy baggage first, like HTTP requests (server & client), TCP sockets, filesystem access.

__s 2y ago

Important to include the preceding "With GC," In theory you can import DOM functions from runtime & call with references to dom objects now, bypassing JS to call directly into runtime (I say in theory because I'm not in the know whether this is actually possible, but GC at least brings prerequisite mechanisms to get to that point)

posix86 2y ago
How does GC help with that?
- __s 2y ago
  GC feature in wasm extends to having opaque references outside linear memory (which may reference objects controlled by host system's gc) avoiding need for js caller to handle resource being freed by wasm code with a pool or something keyed by handles (integers) passed to wasm
- SpaghettiCthulu 2y ago
  I think it would enable WASM code to hold references to DOM objects that have been designed around garbage collection.

josephg 2y ago

I've been playing around with leptos for rust lately - which is a super fast framework for doing web frontend work with rust via wasm. It seems fine, honestly. Basically the same as solidjs: #[component] fn App() -> impl IntoView { let (count, set_count) = create_signal(0); view! { <button on:click=move |_| { set_count(3); }> "Click me: "{move || count()} </button> } } There's some extra size overhead from wasm compared to javascript, but its honestly not that bad. After wasm-opt and brotli compression, the wasm bundle for this counter app is 37kb. So its in the same general ballpark as react, but much faster once its up and running. I haven't tried doing direct DOM manipulation with it. But for general components it seems great.