yew
yew copied to clipboard
yewstack
Virtual DOM is too coupled to Yew Framework
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.
Related issues matching "vdom": https://github.com/yewstack/yew/issues/482, https://github.com/yewstack/yew/issues/126
Related issues: https://github.com/yewstack/yew/issues/343, https://github.com/yewstack/yew/issues/324
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.
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.
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
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.
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.
