Virtual DOM is too coupled to Yew Framework

[jstarry]

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]

Related issues matching "vdom": #482, #126

[kellytk]

Related issues: #343, #324

[pickfire]

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]

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]

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]

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.