6 ms·
The virtual DOM idea is nowadays a myth. It stems from the time when Facebook was still a Web App and was running on IE8 and IE6. It was a decent idea to optim
by _the_inflator 4y ago
The virtual DOM idea is nowadays a myth. It stems from the time when Facebook was still a Web App and was running on IE8 and IE6.
It was a decent idea to optimize for these browsers and FB's nature of featuring hundreds of comments etc. that could be updated somewhere outside your view port and cascade nevertheless into repaints and reflows. Remember the FB feed?
I also worked on virtual DOM optimizations back then for these IEs, but have long since abandoned optimizations. I take it with Svelte: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead
Also Google sheets results show overall, that DOM is faster than any virtual DOM, so why produce overhead? https://millionjs.org/benchmarks https://millionjs.org/benchmarks
Virtual DOMs are a thing that people long time ago forgot why and for what technology it was invented. Then came Google Chrome and their optimizations.
For benchmarks, I think this is still the best around: https://krausest.github.io/js-framework-benchmark/current.html https://krausest.github.io/js-framework-benchmark/current.ht...
- toxicFork 4y agoIt feels nicer to use functional components with declarative state than set dom attributes imperatively.
- jsf01 4y agoPlenty of libraries have functional components and a react-like experience without the need for a virtual dom. Lack of vdom does not necessitate imperative dom usage.
- hinkley 4y agoIt’s the same observation TDD makes. If you can figure out what a sane interface looks like, it doesn’t matter how it’s implemented underneath. You might even want to change your mind for performance or new feature purposes.
- LAC-Tech 4y agolit-html is similar to the render method of a react component, uses a declarative html'esque syntax, and doesn't use a VDOM AFAIK. No one is saying update DOM elements manually. They're saying there's better strategies for view libs than VDOM.
- 7sidedmarble 4y agoThat's kind of an entirely different paradigm, considering lit is a Custom Elements framework.
- baobob 4y agoOver a certain size, some level of abstraction will usually produce a meaningful reduction in code size in most applications. It's possible for some applications a virtual DOM is the abstraction to achieve that, although I don't think I've seen this in practice. It would require an absolute mountain of "document.createElement() / appendChild() / setAttribute()" code before the lighter syntax of a virtual DOM would net a meaningful size reduction with a modern compressor like Brotli. Just saying there are probably situations where these might still offer a genuine functional benefit, simply by virtue of offering abstraction. There are a bunch of replies here focusing on how nice to use virtual DOMs can be, would gently encourage those folk find another industry to ruin.
- bedatadriven 4y agoThe VDom was never intended as a performance optimization over direct dom manipulation. It is a tool to make functional reactive programming style _almost_ as performant as direct dom manipulation. The comparison that's relevant here is, how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes? Compared to rebuilding the dom tree on every change, using a vdoms and diffing offer a huge speedup. Using jquery/vanilla js to update thr dom in an adhoc fashion in response to user input (when the user clicks "next", then add a class to this dom element, remove this other element from this other random place...) has always had faster runtime, it's just more likely to be coded wrong. FRP is an abstraction that makes writing and reasoning about correct UIs easier. Vdom is a technique that makes this abstraction practical.
- nailer 4y agoThe link in the previous comment explains why the virtual DOM is overhead, and you haven’t responded to that. Svelte and other current gen compiler-based approaches allow FRP and do not require a virtual DOM.
- peoplefromibiza 4y ago> how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes? you don't need vdom to make this fast. you compute your state in whatever data structure you like and then requestAnimationFrame updates the DOM if and where it is needed. VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW.
- anonymoushn 4y ago> VDom is much like double buffering in video games, it was useful when video memory was scarce and access times were slow, but it has lost much of the appeal on modern HW. It's funny to read this when Google Chrome has constant tearing on Windows.
- 4y ago
- dan-robertson 4y agoI don’t really understand what you’re point is? Isn’t the ‘dom is slow’ thing about comparing to e.g. - creating actual DOM elements during render and diffing that with the DOM, or - using the existing DOM as the thing being diffed against your new vdom (slow because calling into the browser many times may be slow and you need to check eg there aren’t attributes to be removed from your elements) Perhaps it’s also necessary to mention that the main point of vdom was to allow react to offer the API it does performantly but maybe with compiler-based solutions like svelte that isn’t necessary. Lots of people still use react, however.
- deleted 4y ago[deleted]
- supermatt 4y agoTo my understanding, the virtual DOM used for efficient "diffing" of the subtrees - i.e. producing the optimal set of DOM updates required. If you are building any abstraction on top of the DOM to handle that, then you have effectively built a virtual DOM. Or are you suggesting that setting innerHTML and allowing the browser to re-construct the DOM is now faster? I can assure you that is not the case!
- jesse__ 4y agoLook at their benchmarks. They compare against innerHTML and against (I assume) inserting new DOM nodes. Million is slightly faster than the former, slightly slower than the latter. DOM manipulations are fast these days
- supermatt 4y agoWow, im surprised at how fast that is now - although the benchmarks themselves are doing bulk ops for all the innerHTML stuff, so it will lose some UI state (cursor, etc) TBH, looking at the benchmark code for partial updates, im not sure I have much faith in the benchmarks overall, but certainly eye-opening regarding the innerHTML performance.
- jesse__ 4y agoYeah I was surprised at the numbers too. I'm wondering if those numbers actually imply that reconstructing the Dom from scratch every update is now faster than using a VDom..?
- pyrale 4y ago> Then came Google Chrome and their optimizations. I'd be curious to know whether this holds true for other browsers out there.
- hajile 4y agoInfernoJS uses a vdom is faster than Svelte in the js framework benchmark. Even if we set that aside, the differences between something like Svelte and React are still likely to be far less than the differences you'll gain from changing to a more efficient algorithm.