Hacker News Reader

Comment by zackoverflow | Hacker News Reader

I have seen a few of these Rust front-end projects, they are all really great except for the fact that very few support SSR. This is especially important given the fact that it is much slower sending wasm over the wire and instantiating the module and the wasm environment vs plain js

I'm not sure if this is because of the complexity of the undertaking (I imagine it would need some sort of virtual DOM) or just lack of interest

View on HN

>This is especially important given the fact that it is much slower sending wasm over the wire and instantiating the module and the wasm environment vs plain js

You might be surprised. JS is a very slow language to parse. WASM was designed to be parsed quickly. And browsers have implemented streaming compilation for WASM, which means once the last byte comes over the wire, 99% of the work is already done.

Check out js-framework-benchmark[1] startup metrics. The page weight for Yew (another WASM framework) is pretty heavyweight at 300KB, but it has a consistently faster time-to-interactive than vanillajs.

[1]: https://krausest.github.io/js-framework-benchmark/current.ht...

What makes you think sending WASM over the wire is slower? The payloads should be smaller than JS, assuming you aren't shipping a runtime alongside your code (which Rust doesn't). I don't know about the bootstrapping side, but I know some people use WASM specifically for the small bundle sizes.

thanks for the correction, was formulating the sentence and somehow "wasm over the wire" injected itself in there. 100% transfering wasm in the binary format is a more efficient transfer than js.

The Rust compiler and ecosystem are tuned more towards generating faster code rather than generating smaller code. In my experience, even small wasm apps that are careful about their dependencies end up shipping hundreds of KB of wasm over the wire, and if you're not as careful that easily tips over to MBs.

Time and space are in tension, and the web is more sensitive to binary size than most other targets, including many embedded targets.

To take one example that often contributes a ton to binary size, consider data serialization in Rust vs JS. JS will tend to just use JSON.parse and deserialize into a JS object with little to no data validation. The JS object is then exclusively accessed via dynamic field lookup (with a JIT doing its best to notice patterns and hopefully optimize the hot paths). The same code paths can handle many different message shapes. It's far from optimal in terms of runtime speed, but the code can be made very compact.

Rust deserializers by contrast seem to use compiler-time code generation to produce a different optimized struct layout, parser, and validator for every message type. When I've played with writing very small Rust + wasm apps, the choice of serialization library and format made a huge difference. If I recall correctly, using BSON + serde would have increased my total binary size by more than 3x.

This isn't a fundamental issue with Rust as a language, I think it's partly still early days for the tooling.

There is, however a certain fundamental amount of tension there in what's optimized for. In most environments, 30% faster deserialization for a binary that's 500KB larger (pulling numbers out of my ass) is in the "obviously yes, do that" category, but on the web adding 500KB to your binary is a steep price to pay, particularly for mobile users.

I have been working on a virtual DOM library which will enable a few of these projects to support SSR. But, partly due to lack of interest, and partly due to lack of time on my part, it’s been going slower lately. Still, the effort is ongoing.

https://github.com/rust-rdom/rust-rdom

Helpful acronym bot here.

* SSR = server side rendering

Related terms include:

* CSR = client-side rendering

* PWA = progressive web app

P.S. I am not a bot. (But don't all bots say this?)

Good bot

Thanks, this is great. I see the readme mentions the project was created for yew, how far is from being ready to work with it?

There are two steps there: (1) rust-rdom working enough to be used by Yew, and (2) SSR support built out in Yew utilizing rust-rdom. Part (2) is pretty far away, but (1) is probably about halfway there. I think a more realistic use-case for the library is Sycamore which is much earlier and simpler than Yew. Sycamore support has a tracking issue here: https://github.com/rust-rdom/rust-rdom/issues/15

Reply on news.ycombinator.com