> You can't just pipe wasm to the client to get the same effect.
I know what SSR is and you can do it[1] in Rust, where you write type-safe, compiled Rust code and send HTML/CSS/WASM to the browser. SSR was originally developed in things like Perl and PHP -- there's nothing language-specific about it.
> Besides being less efficient than JS at manipulating the DOM
Some applications manipulate DOM a lot (and WASM isn't slow enough for a well-written app to be noticeably slower to a user) and some applications do a lot of processing before changing the client. WASM will be dramatically faster at the latter.
> I know what SSR is and you can do it[1] in Rust, where you write type-safe, compiled Rust code and send HTML/CSS/WASM to the browser.
Yeah, but that way your frontend team is forced to develop in Rust, instead of develop in JS/TS. What I want to do is enable FE devs/team to do their job (writing JS/JSX) happily ignoring the server, and at the same time do SSR on the server happily ignoring how FE devs/team implemented the view.
You might notice, "ok but they need a contract to know which is the data shape that the server is going to provide to the JS/TS render() call"; yep, that's one of the challenges of what I'm trying to do :D
I know what SSR is and you can do it[1] in Rust, where you write type-safe, compiled Rust code and send HTML/CSS/WASM to the browser. SSR was originally developed in things like Perl and PHP -- there's nothing language-specific about it.
> Besides being less efficient than JS at manipulating the DOM
Some applications manipulate DOM a lot (and WASM isn't slow enough for a well-written app to be noticeably slower to a user) and some applications do a lot of processing before changing the client. WASM will be dramatically faster at the latter.
1. https://wasmedge.org/book/en/write_wasm/rust/ssr.html