Seed without VDOM?

[MartinKavik]

@MartinKavik Off-topic, I am wondering if seed will ever look into not using virtual DOM?

Originally posted by @pickfire in https://github.com/connorskees/grass/issues/4#issuecomment-653845842

---

I/we understand VDOM as a big implementation detail. We'll focus on it once Seed API is stable (you can read guides on seed-rs.org with notes about future improvements). So yes, it's one of the possible options. See the list in https://github.com/seed-rs/seed/issues/385 - there are some interesting links and ideas related to VDOM or alternatives.

[pickfire]

dominator is a rust web framework without VDOM like svelte, yew is also currently looking into that https://github.com/yewstack/yew/issues/758

[MartinKavik]

dominator is a rust web framework without VDOM like svelte

Yeah, they are on that list already.

@pickfire What's the motivation for the question? Do you haven any problems with Seed VDOM?

[pickfire]

No, I was just wondering why everyone targets VDOM when there are frameworks like svelte that targets DOM which gives it performance boost, I wonder if it is possible to not have VDOM. Like GC, it may seemed to be needed at first but then it was removed in Rust.

[MartinKavik]

No, I was just wondering why everyone targets VDOM when there are frameworks like svelte that targets DOM

Everything has trade-offs. And there are different trade-offs for JS and Rust frameworks.

Seed uses VDOM because:

• It's easier to try and develop new Seed features and better public API when the ugly/cumbersome low-level browser API interactions are hidden under the VDOM abstraction.

• There isn't a native Rust/non-JS browser API yet - it means that all items passed during browser/DOM calls from Rust (WASM module) to browser have to be transformed to JS types and then used. It's slow and often cumbersome. That's why the most Rust frameworks are still slow in benchmarks that test DOM changes speed.

• Rust is much faster than JS - it means that VDOM diffs are also much faster.

• Theoretically, we can target non-browser platforms with VDOM. In practice, server-side rendering should be easier to implement in the future with VDOM; and many unit tests could be written without real DOM manipulations.

• The biggest Seed performance problem is the initial render with MANY elements because of slow JS/DOM calls to create elements. We plan to mitigate it probably by sending a one HTML string generated by VDOM to JS world to create the whole DOM tree at once.

• We want to write as little JS code as possible in Seed to not introduce bugs. There are already very fast Rust VDOM libs that use unsafe code and JS helpers. Seed doesn't use them at all. I assume we would need to use JS code or more complex Rust-JS bridge without VDOM.

• We'll be integrating Seed Hooks + Atoms and Seed Styles into the Seed soon (https://seed-style-hooks.netlify.app/). VDOM should make the integration less error prone and faster.

• There were/are no real reasons to remove VDOM.

It's possible we'll find reasons (and time) to remove VDOM, but neither deeper investigation nor removing is planned in the near future.

[rebo]

In my experience VDOM diffing doesn't seem to be the slowest part of the render process in seed. Indeed even though it isn't really optimised at all at the moment it's still really quick. With some optimisations it can be made even quicker.

I think a move to svelte style direct dom patching would possibly require a lot of re-engineering but at the same time potentially constraining other apects of Seed.

[rebo]

Despite what I said, I just couldn't help myself.

Svelte/SolidJS/ImbaJS/Valerie-rs style direct DOM patching without V-DOM works just fine in Seed.

I'm sorry I promise I will stop now and write some documentation for normal hooks and do a style integration plan :).

POC:

pub fn view(_model: &Model) -> Node<Msg> {
    let name = use_state(|| "rebo".to_string);

    div![
        p![
            name.el_class(),  
            name.inner_text(),
        ],
        button![
            "Click Me",
            name().on_click(|n| *n = "bob".to_string())
        ]
    ]
}

This sets the paragraph text and class directly to name whenever it is changed/updated. This completely bypasses the virtual dom, no virtual dom is needed to be regenerated and no reconciliation is necessary.

name could be an Atom or (as shown) a use_state State. Just like Svelte on first render it would render the dom as usual. On later updates to the state the browser dom is directly updated to reflect the new state.

Anyway enough of this silliness, time to do something productive!

[pickfire]

@rebo Interesting

In my experience VDOM diffing doesn't seem to be the slowest part of the render process in seed. Indeed even though it isn't really optimised at all at the moment it's still really quick. With some optimisations it can be made even quicker.

Maybe we could try benchmarking the simple demo you did with dom and without (I don't know how)? Or maybe do it on a more advanced example. I wish it makes stuff faster but it would be good if it can be used only for server and not on browser for SSR.

I think a move to svelte style direct dom patching would possibly require a lot of re-engineering but at the same time potentially constraining other apects of Seed.

After your experimentation, do you think that is still true?

[rebo]

After your experimentation, do you think that is still true?

I have mixed thoughts, vdom-less infrastructure seems to require accurate change detection, basically the system needs to understand when a specific value has been changed and then propagate that effect to directly modify the browser dom. It's not a trivial problem.

For specific values like strings or attribute classes (as in the example above) this is not too complex however it might not be the same for more complex changes such as changing an entire UI tree. And for all of this effort what is gained? Some speed. Sure, maybe even a large speed boost. But is Seed that slow in the first place? It's not that bad to be honest - I can already render tables backed by 100,000 rows at 200+fps. Not sure where I need more performance than that.

What might be nice is to have these tools available as an optional optimisation for those situations that really need do it.

[awulkan]

I can already render tables backed by 100,000 rows at 200+fps. Not sure where I need more performance than that.

The place where Svelte and similar frameworks shine is on low powered devices. They have real world examples of people using Svelte purely because all other options were too slow for their use cases.

[MartinKavik]

They have real world examples of people using Svelte purely because all other options were too slow for their use cases.

@awulkan Could you post links to some of those examples? I would like to know what apps they build and what hardware they use.

[awulkan]

They have real world examples of people using Svelte purely because all other options were too slow for their use cases.

@awulkan Could you post links to some of those examples? I would like to know what apps they build and what hardware they use.

One example is https://www.stone.co for their handheld devices. I remember reading somewhere that they use Svelte because of the performance. You can also find their logo on Svelte's website.