I haven't see any project which feels fast which are written in React. But most important thing for me which is broken (because it is too difficult to catch all edge cases) in all the JS frontends is the broken navigation (browser's back and forward almost never work as expected, bookmarking links are broken because state is in JS etc.)
Virtual DOM is pure overhead (2018)
51–60 of 337 posts
Re: Virtual DOM is pure overhead (2018)
#52All abstractions are pure overhead. Let's code everything by hand by flipping bits in memory using a tiny magnetic needle.
This is over-simplified: the overhead of an abstraction can be cancelled out by work or optimizations which you wouldn't have done without the abstraction. As a simple example, most Python programs are faster than the C code the same developer would have written in the same time because they have a rich library of optimized code and getting it working quickly means that they had more time to focus on algorithm-level improvements. That of course doesn't mean that a C programmer can't beat it in performance but once you're past very simple examples those abstractions are harder to beat than they might seem — I've seen multiple cases where someone thought they could do that and wasted days (or in one case, months) only to eke out less than a 10% improvement.
In this case, React is slow and memory hungry because when you make a change you go through this process:
1. Update some value
2. … triggering updates to the virtual DOM
3. … requiring it to caluclate the difference between the real DOM and the virtual DOM
4. … and finally apply the changes to the real DOM
That abstraction requires substantial extra state to be stored and managed. If you have a different abstraction which directly manages the DOM, you can avoid steps 2 and 3. The big question is a) does your code do enough manipulation for this to be noticeable? (React is less slow than it used to be but I've seen 4 order of magnitude deltas in optimized React code so it's not uncommon to see it chug with large pages, especially on older hardware like a lot of the public uses) and b) does that other abstraction have drawbacks for your developers which cost you more than the performance savings?
Re: Virtual DOM is pure overhead (2018)
#53Poorly written react code isn't performant and removing the Virtual DOM will not fix your problem. It's a hill I'm willing to die on. Many engineers seem to struggle with unnecessary re-renders, to the point where I see long tasks in the performance tab. Clicking a button shouldn't lock the UI thread for 2 seconds.
I don't think that many junior/early mid React developers know that the whole tree gets re-rendered.
Those that do, I don't think they fully understand when and where to `useMemo` and `useCallback` to optimize. It tends to get overused or used in a way that doesn't actually memoize the parts of the component that doesn't change.
Then adding in state management only makes it more complicated in some cases depending on the state paradigm.
It's a mystery that React is as prevalent as it is given how hard it is to actually do well. I think Solid.js and Vue have a much cleaner paradigm as far as re-renders goes (with React being explicit opt-out and Solid and Vue being opt-in).
Re: Virtual DOM is pure overhead (2018)
#54https://twitter.com/dan_abramov/status/1135424423668920326
Above thread summarizes the issue pretty well I think. Optimizing for DOM updates is nice, but you also want to optimize for bundle size and page load time, and at a certain app size the compiler output is always going to be bigger than just using a virtual DOM.
Re: Virtual DOM is pure overhead (2018)
#55Sadly, it seems like nobody is considering the best optimization: make DOM operations fast. I think if you could batch DOM operations together you could avoid a lot of wasted relayout and duplicate calculations.
Agreed, I'd love to see HTMLElement.beginTransaction() or something similar.
Document fragments are like transactions for the DOM. Alternatively you could just learn which Dom operations force a layout shift and batch those.
Re: Virtual DOM is pure overhead (2018)
#56Can we please talk about how much reactive programming sucks for UIs?
I miss all the people who switched from angular to react for a reason in these discussions... I'd bet none of those are going to move to svelte.
Re: Virtual DOM is pure overhead (2018)
#57The key observation about HTML templates is that usually large portions of them don't change with new data. There is static content, and even with lots of dynamic bindings they're tied together in a static structure. So the vdom approach of processing all the static parts of a template during a diff is just extremely wasteful, especially for fairly common cases like conditionally rendering a node before some static c…
I'm sure there's a different concept in there somewhere, but what you described sounds exactly like vdom.
This model doesn't represent DOM nodes, it represents entire templates. And there's no per-node diff - you only compare bound values. So the structure of templates is entirely static.
Re: Virtual DOM is pure overhead (2018)
#58Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast . Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base…
I agree. Getting kind of sick of these posts that are thinly veiled political campaigns against the other framework. Great libraries tend to speak for themselves in terms of adoption. You shouldn't have to convince people not to use other options.
It’s not always bashing other frameworks gratuitously; an important aspect of human progress is recognizing what works well, what works less well, and what seemed like a good idea at the time but either became obsolete or was a bad idea to begin with.
JSX and VDOM were at one time necessary (or at least helpful), but Web Components and Tagged Template Literals can do everything React does, only better and with less overhead (in both the developer’s mind as well as the computer’s runtime). I say that as someone who learned and taught bootcamps with React, and has yet to dive too deeply into lit-html and LitElement.
Re: Virtual DOM is pure overhead (2018)
#59I like the looks of Svelte, but this argument is a bit strong. The supposed benefit of virtual DOM being: X 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…
None of the good frameworks really do any more DOM operations than any other. It's all about how you find out which set of DOM operations need to be done. Svelte does this with a compiler, Lit does it with tagged template literals, and a bunch do it with vdom. Calculating the vdom diff is pure overhead in that if you have better syntax (or a compiler) you can just skip it.
They don't because since React set the bar, any new framework that didn't solve the problem VDOM did in some way, was dead on arrival.
If Svelte way is better at minimizing and batching DOM updates, they should probably argue and show that, not misrepresent what VDOM does (while blaming strawmanning on others no less).
Re: Virtual DOM is pure overhead (2018)
#60The key observation about HTML templates is that usually large portions of them don't change with new data. There is static content, and even with lots of dynamic bindings they're tied together in a static structure. So the vdom approach of processing all the static parts of a template during a diff is just extremely wasteful, especially for fairly common cases like conditionally rendering a node before some static c…
This is also a core design principle of Angular - the compiler extracts the static template structure and generates code to update dynamic bindings within it.
Yes, but it turns out that you don't actually need a compiler for that. You can do it in a runtime that's very small because the standard JS syntax already separates the static structure for you.