[chrisco255]

SSR is the process of generating the HTML and CSS necessary to render a web page on the server side before it's sent down the wire. You can't just pipe wasm to the client to get the same effect. Besides being less efficient than JS at manipulating the DOM, the idea is that everything is already available and streamed to the client for optimal render speed.

[smt88]

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

1. https://wasmedge.org/book/en/write_wasm/rust/ssr.html

[izietto]

> 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