Anyone wanna make a Rust VDOM

1

Now that rust can compile using emscripten, does anyone fancy helping to make a VDOM (virtual DOM) lib. Here's how it works (ish):

After every change, a new object representing the next DOM state is passed to our runtime. Our runtime is then responsible for comparing this new state with our current state and computing the minimal list of changes to convert the old to the new. This list is then run on the DOM to update it to the new state (see this diagram for a visual representation).

Using this method allows for much faster webapps than replacing the whole DOM (DOM operations are expensive), and it promotes declarative styles of UI design, leading to much more maintainable code, as there are less hidden links between different parts of the DOM. I've just had first hand experience of this working with some React code I wrote a few years ago. I can't remember writing it, but I can figure out how it works pretty easily by tracking how the data flows from the root down into all the components.

Currently there is no webassembly standard to access the DOM, so access is gained by using javascript middleware. Some time in the future it may be possible to bypass this and make "C" style calls to alter the DOM directly.

I believe this is how Conrod works, so maybe ideas (or even code) could be borrowed.

Anyone interested? It's graph theory (= fun!) and I don't really have a clue so could do with some help :stuck_out_tongue:

2 Likes
2

Like this? https://github.com/antoyo/relm

1 Like
3

I quite like how https://github.com/Matt-Esch/virtual-dom works, there's a very clear split between

  1. Creating a tree of simple data objects representing the virtual DOM.
  2. Rendering the virtual DOM tree into an "opaque" real DOM object.
  3. Diffing an existing virtual DOM tree and a new virtual DOM tree to get the changes that would have to be made to the real DOM to transition from one to the other.
  4. Applying a set of changes to a real DOM object.

I have in the past attempted building something similar where different steps could run in different contexts (using multiple background workers) and the big issue I found was hooking up events back from the real DOM to the context where they needed to go. That's likely to be an issue for a Rust VDOM library as well, since you're not running in the same context you won't be able to assign callbacks directly and will have to proxy them through the library somehow. Either via actually taking in Fn callbacks and setting up some sort of central dispatcher for them, or using a completely different method to handle the DOM events.

1 Like
4

https://github.com/cramertj/domafic-rs

1 Like
5

Some notes from a year ago

6

Thanks for the comments - very helpful! Looks like there's been some good work already (as there always is) - I'll have to browse it all!