From looking at it for like 20 seconds (I ain't no serious rustacean, so forgive if I'm wrong) I think they're using just a growable pool (as vectors) of each fundamental type in the Go language, then having each instance of each fundamental type be boxed in a Rc (reference counted) type so that they can count all references to each instance of each fundamental type.I believe that this can be used to get simple reference counting "for free" via the borrow checker of Rust. Probably many downsides, and apparently they don't yet implement GC of channels, but it seems like a nice straightforward way to get a script-ing/purely interpreted implementation of a language off the ground.
How should one approach learning about building a virtual DOM? Are there any particular resources or pieces of literature you recommend taking a look at?
Sure! I don't recommend any of the React-based virtual DOM articles yet, often they're pretty complicated and will confuse you. I wrote an article here with an even simpler implementation of the virtual DOM: https://dev.to/aidenybai/how-does-virtual-dom-work-b74.
Basically anything that guides you in building a virtual DOM is a good article
I enjoy Go but I don't see it playing nicely with wasm anytime soon. It's runtime is big, it has a garbage collector, and getting the complexity and nuance of goroutines to work in the browser with webworkers seems like a scary challenge.
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
>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.
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.
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.
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.
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.
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
