[ElectricSpoon]

> 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.

[__s]

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]

How does GC help with that?

[josephg]

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]

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.