Virtual DOM is pure overhead (2018)
svelte.dev
Virtual DOM is pure overhead (2018)
1–10 of 337 posts
Re: Virtual DOM is pure overhead (2018)
#2Re: Virtual DOM is pure overhead (2018)
#3Re: Virtual DOM is pure overhead (2018)
#4Re: Virtual DOM is pure overhead (2018)
#5Re: Virtual DOM is pure overhead (2018)
#6So is the JS runtime. So why don't we just write apps in raw WASM?
Re: Virtual DOM is pure overhead (2018)
#7So is the JS runtime. So why don't we just write apps in raw WASM?
If we're rethinking the web stack I'd advocate for htmx with wasm-based web components for more complicated stuff like if you needed to polyfil in some new image format, or run a terminal emulator, or do webrtc calls with your own fancy custom noise reduction algorithm.
Yes I realize I'm essentially advocating for jquery with java applets, but it could really work this time! (I think a lot of the issues originally were political)
Make htmx like attributes part of the HTML spec, keep working on web components. Still don't know why web components haven't taken off.
Re: Virtual DOM is pure overhead (2018)
#8Even open source projects are guilty of this type of grifting, everyone wants to win, even without money in the game.
Re: Virtual DOM is pure overhead (2018)
#9Re: Virtual DOM is pure overhead (2018)
#10X application-level virtual DOM changes -> differ detects only Y Y final DOM operations
is faster than
X application-level virtual DOM changes -> no virtual DOM diffing -> X DOM operations
this depends a lot of how fast the diffing is and how fast the DOM is but unless DOM operations are instant now (and with CSS, layout reflow, etc. I'm not sure how they could be) then there must remain some situations where VDOM has a perf advantage.