Virtual DOM is too coupled to Yew Framework

yewstack / yew

Rust / Wasm framework for creating reliable and efficient web applications

https://yew.rs

Apache License 2.0

30.36k stars 1.42k forks source link

Virtual DOM is too coupled to Yew Framework #758

Open jstarry opened 4 years ago

jstarry commented 4 years ago

Description

Yew's Virtual DOM implementation is too coupled to the framework and should be moved to a different crate if possible. This would allow other backends to be used with Yew in the future.

kellytk commented 4 years ago

pickfire commented 4 years ago

Is there anyway for yew to not use virtual DOM like dominator? What are the implications of not using it? It felt like GC (initial rust) vs no GC (current rust) to me.

teymour-aldridge commented 4 years ago

Everything in Yew is pretty tied to the virtual DOM, but I've been trying to think of ways to move away from using a virtual DOM.

rchavezj commented 2 years ago

I don't how svelte does it but they created a declarative javascript language that gets compiled to efficient vanilla js imperative code with no virtual dom.

I would imagine looking inside the svelte's compiler as a starting point to go from rust+wasm to efficient vanilla js with wasm

ranile commented 2 years ago

I don't how svelte does it but they created a declarative javascript language that gets compiled to efficient vanilla js imperative code with no virtual dom.

I would imagine looking inside the svelte's compiler as a starting point to go from rust+wasm to efficient vanilla js with wasm

The problem with going that way in WASM is that making DOM API calls is more expensive than querying in-memory VDOM. For write operations to the DOM, this isn't an issue but for read operations (such as for diffing, etc), this can cause performance issues.
PS: I haven't benchmarked anything.

andersk commented 2 years ago

The problem with going that way in WASM is that making DOM API calls is more expensive than querying in-memory VDOM.

The alternative to diffing with a virtual DOM isn’t diffing with the real DOM. (Well that is an alternative, but yes, it’d be very slow.) The way the fastest modern JS frameworks work is by remembering the graph of dependencies from individual DOM nodes to individual pieces of reactive state, and using it to directly update only the affected DOM nodes when some of the state changes.

This of course has implications for the API, which has to be adjusted to allow these dependencies to be tracked. This ten-minute SolidJS introduction is worth watching to understand how that could work in practice.