3 ms·
> Frameworks like React with virtual DOMs help you by redrawing on every state change, which will typically both speed things up significantly and also carry yo
by samwillis 3y ago
> Frameworks like React with virtual DOMs help you by redrawing on every state change, which will typically both speed things up significantly and also carry you through a lot of things that would break if you were using non virtual DOM frameworks
A virtual DOM based framework will not be faster than manual DOM manipulation with either vanilla JS or even JQuery. It certainly makes development easier, and massively reduces the risk of bugs. But there is no magic to a VDOM and speed, technically you are usually doing more work, building a VDOM and diffing it.
Edit:
Rich Harris of Svelte has a good post explaining:
> Virtual DOM is pure overhead. Let's retire the 'virtual DOM is fast' myth once and for all
https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead
- p-e-w 3y ago> But there is no magic to a VDOM and speed There absolutely is. If you are using standard DOM APIs and are first changing the text of a <span> element, then changing it back to what it was before (which can easily happen if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI), the browser will have to re-render the element twice, which means two full re-layouts unless the element is absolutely positioned or something. By contrast, VDOM-based frameworks will detect that the DOM hasn't actually changed, and as a result, the browser doesn't have to do anything (other than update the VDOM). That's indeed "magic", and makes a tremendous performance difference with complex applications in practice.
- samwillis 3y agoNo, in a correctly implemented pure DOM manipulation app you would update the DOM once to match your state, that's faster than building a VDOM and diffing it. Modifying the DOM twice, with an unintentional reflow and redraw between, would be a bug in your code. Yes, "if your application logic is sufficiently complex, with multiple piecewise state changes impacting the UI" is what a VDOM helps with from a developer perspective. But it isn't magically "faster". Personally I'm a fan of reactive frameworks such as Vue that do use a VDOM, but also by using a reactive state can do fine grain partial rendering of that VDOM for efficiency. Would I build an app without a (probably VDOM based) framework, no I wouldn't. Also note that the "fastest" frameworks, such as Solid, don't use a VDOM, they track state changes and do fine grade DOM manipulation to match it.
- TylerE 3y agoWho needs memory safety? Just correctly use malloc and free on every possible code path. Easy and simple!
- samwillis 3y agoVDOM isn't the equivalent of memory safety - such as using Rust over C, its much more similar to using a garbage collected high level language - such as Python or Ruby - over C. Your implied comparison doesn't work.
- chrisco255 3y agoVDOM has nothing to do with garbage collection. VDOM is a cache.
- FpUser 3y agoI do not use any frameworks for browser based JS/HTML front ends. Just plain JS and some domain specific libs when needed. No problems so far and the resulting GUIs are fast.
- treeman79 3y agoSo different from Netscape / internet explorer 3 days. Especially anything to do with corporate that insisted on ancient versions of Internet explorer. Can you write the app when you almost have to rewrite it and get it to work with Internet explorer
- azangru 3y ago> If you are using standard DOM APIs and are first changing the text of a <span> element, then changing it back to what it was before ... the browser will have to re-render the element twice As far as I understand, not if this all happens within a single browser layout/paint cycle [0] - [0] https://twitter.com/jaffathecake/status/1552242563654066176 https://twitter.com/jaffathecake/status/1552242563654066176
- ricardobayes 3y agoHuh? You're not doing any of this, the framework does it automatically. The virtual DOM and DOM change reconciliation makes it faster. DOM changes are really slow. The reconciliation makes sure only the parts are re-rendered which have changed. Failing that, the full screen is re-rendered. If you're doing manual VDOM building you're doing something very wrong.
- samwillis 3y ago> If you're doing manual VDOM building you're doing something very wrong. Rendering a React or Vue component is building a VDOM, that's what I'm referring to. Your code is explicitly building a VDOM. > The reconciliation makes sure only the parts are re-rendered which have changed. Yes, and that makes development easier. That reconciliation is only "faster" if your alternative non-VDOM code is poorly written, throwing away chunks of DOM and rebuilding from scratch. I'm not advocating for not using VDOM frameworks, I use them, I'm advocating for understanding they are not faster than the DOM. that is a myth, and results in people misunderstanding the tools or how the DOM and browsers work.
- ricardobayes 3y agoYeah I definitely agree with VDOM doesn't necessarily speed up anything on its own. There are many frameworks that benchmark better than react, for example - svelte, lit - these don't have VDOM at all.
- devjab 3y agoYou wrote this later and I apologise for bringing it up here: > a correctly implemented pure DOM manipulation app you would update the DOM once to match your state, that's faster than building a VDOM and diffing it Bur that is sort of my point. Maybe I could have been clearer about it, but my intend was to say that the VDOM frameworks are faster (or perhaps safer is the right word) for people who aren’t doing things correctly. Which among others is also me.
- samwillis 3y agoNo worries, and the rest of your comment (DOM actually fast, render+reflow slow, Electron good choice) is good. It just bugs me when people repeat the myth that VDOM is faster at rendering than native DOM (or not clearly explaining otherwise), it encourages people to reach for a tool they don't necessarily need. As I have said in other comments, VDOM based frameworks are good, people should use them, but not because they are "magically" faster.
- junon 3y agoSurplus, which predates svelte and does much the same thing, also uses no vdom and has topped out performance benchmarks for a long time.
- pier25 3y agoAnd yet, InfernoJS is faster than Svelte while using a VDOM.