Virtual DOM is pure overhead (2018) • Hacker News Board

Re: Virtual DOM is pure overhead (2018)

#101

Post by bmuon » Tue, Jun 29, 2021, 2:41 PM UTC

preommr wrote: post #37

I've never really bought into this. The diffing is mostly an implementation deatil that is abstracted away. React could check to see if props.items changed instead of the nonsense it does. If it still does that in 2021. The thing is vue uses getters and setters that would trigger direct changes without needing to diff the entire tree. It could theoretically be really fast, but it still used a virtual dom, and it was…

> I am convinced that if react really wanted to, they could make optimizations to make it really close to svelte

Facebook has been working for a while on Ahead-Of-Time compilation for React. Interestingly, it looks like they thought the problem was too complicated and they gave up:

> To address this challenge we initially experimented with one approach to ahead-of-time (AOT) optimization — Prepack — but ultimately that direction did not pan out. Specifically, we realized that many AOT optimizations don’t work because they either don’t have enough global knowledge or they have too little. For example, a component might be static in practice because it always receive a constant string from its parent, but the compiler can’t see that far and thinks the component is dynamic. Even when we could make optimizations work, we found that they were unpredictable to the developer. Without predictability it was hard for developers to rely on them.

Instead they're now experimenting with moving the virtual DOM resolution to the server and avoiding sending all the "templating" code to the client, which achieves a similar result. See https://reactjs.org/blog/2020/12/21/data-fetching-with-react....

Re: Virtual DOM is pure overhead (2018)

#102

Post by protonimitate » Tue, Jun 29, 2021, 2:42 PM UTC

yladiz wrote: post #96

protonimitate wrote: post #74

Earlier quoted context omitted.

> React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output. Svelte has been around for a few years now - and I've yet to se…

> performance of front end frameworks is near the bottom of my evaluation checklist Sorry to pick on this point but depending on your application this should be more (or much more) important. Too many teams have this same opinion and it's glaringly obvious how little they care about performance. I'd agree that raw performance isn't really important, but the ways you can and the tools you have to optimize the performa…

Maybe I worded that incorrectly - yes performance is important. But the negligible gains between framework x and framework y are not high on my evaluation checklist, as long as the minimum performance requirement is met (which is often dictated by the product requirements).

I've been working in React for ~4 years now, at all types of scale. While I've definitely seen performance issues, it's never been a case of a flaw in the approach the React takes.

I guess a better way to phrase my point - until I encounter a scenario where the performance is bad enough in React to warrant looking at other frameworks, choosing a framework based on pure performance is an over-optimization.

Of course, this would be a different conversation if React was known for being the one and only bottleneck in web app performance - but afaik that is a rare case.

Re: Virtual DOM is pure overhead (2018)

#103

Post by px43 » Tue, Jun 29, 2021, 2:42 PM UTC

Maybe this is a dumb question from a JS muggle, but the thing that kills me about this whole movement to virtual/shadow DOM is that it's made the "ctrl+f" search useless on more and more websites. Is there a nice way to hook the search function to actually look inside elements that haven't been swapped in yet? If so, more people should be using it.

Re: Virtual DOM is pure overhead (2018)

#104

Post by mumblemumble » Tue, Jun 29, 2021, 2:43 PM UTC

jacob019 wrote: post #79

mumblemumble wrote: post #69

Earlier quoted context omitted.

What's interesting to me, as someone who is currently learning Web development mid-career, is that I can see that vanilla JS is actually a really good option nowadays, but not necessarily available to anyone who's more established. Because it doesn't seem to have gotten good until fairly recently, and, for the most part, everyone had already made the important technical decisions before that happened. So, even if it'…

Vanilla JS gets messy as your app scales. You will end up building a framework.

You've betrayed your bias in your choice of words, though: "app." And, for that matter, choosing the word "as" instead of "if."

I'm not personally building apps, and I'm certainly not building things that need to be single-page apps. I'm building websites. They may be dynamic, they may include interactive elements on the page, but they're still mostly just plain old websites with limited state to manage. Which is fine by me. I suspect, that, were it not for those social constraints I described up above, that would be fine for most websites.

One of the other problems with complexity is that it's addictive. You get a taste of it in a situation where you actually need it, and next thing you know you're afraid to go anywhere without it, because you're worried (or is it hopeful?) that you might need it again.

Re: Virtual DOM is pure overhead (2018)

#105

Post by KronisLV » Tue, Jun 29, 2021, 2:43 PM UTC

FractalHQ wrote: post #77

The most important part of Svelte, to me, is that it allows me to write web applications in the most elegant possible way. The compiler first approach means we get to choose whatever syntax we want to make the whole process as enjoyable as possible. The most brilliant part of Svelte was the decision to stay as close to JavaScript as possible, so anyone who knows JS, HTML, and CSS knows svelte. Importing any vanilla J…

> Importing any vanilla JS library is plug-and-play, meaning the community and ecosystem span the entire JS ecosystem. No more x-for-react or y-for-vue.

This makes me feel conflicted.

With React/Angular/Vue you're given a stable base upon which to build new components and logic, so most of the libraries end up being vaguely consistent with the underlying tech.

With JS libraries it's the wild west once again and before you know it, your components will need 3 different mechanisms of being initialized, their internals will use different approaches, before long you'll have multiple versions of jQuery in there as well and it'll make you consider the downsides of that approach.

But maybe I only have that outlook because I've witnessed many such situations of poorly integrated JS libraries and have therefore gotten used to walled gardens.

Re: Virtual DOM is pure overhead (2018)

#106

Post by protonimitate » Tue, Jun 29, 2021, 2:43 PM UTC

macspoofing wrote: post #97

protonimitate wrote: post #74

Earlier quoted context omitted.

> React sold us the idea that the virtual DOM could give us a better programming model and still outperform the template based frameworks of the day. React, imo, is about the programming experience. "Thinking in React" is a lot more than just VDOM, and the benefit of "thinking in react" is about the developer experience not the pure benchmarkable output. Svelte has been around for a few years now - and I've yet to se…

>Svelte has been around for a few years now - and I've yet to see/hear about an application built with Svelte at scale. What do you mean 'at scale'. It's a UI framework that runs JS and mutates the DOM - there's no issues with 'scale' here. That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it.

"at scale" here means # of contributors, not # of lines or scope of code base.

Svelte vs React on a single side project I work on in my free time by myself is different conversation than Svelte vs React on a team that's moving fast and has more than a single dev.

Re: Virtual DOM is pure overhead (2018)

#107

Post by Yaina » Tue, Jun 29, 2021, 2:45 PM UTC

incrudible wrote: post #82

Ironically, the thing that supposedly no one does (setting innerHTML) in many cases is still much faster than using the finer grained DOM APIs the way React or Svelte would.

I think it's hard to argue that these frameworks are out-of-the box faster than using the DOM APIs directly. What they do is provide abstractions that lets you scale HTML-interactivity up much faster.

Plain-JS DOM manipulation code can become quite complex very fast, and I think that's what opens the door for inefficiency and also a lot of errors, because it's hard to keep track of possible DOM permutations.

Re: Virtual DOM is pure overhead (2018)

#108

Post by sopooneo » Tue, Jun 29, 2021, 2:46 PM UTC

For those who have worked on traditional desktop apps (rather than web), what underlying paradigm is used for UI updates there? I assume all these problems of fast partial updates must have been addressed there long ago. So apart from the specifics miasma of language and markup formats, how was it done?

I ask in complete earnest, and if I should just be reading some particular Wikipedia article I'm grateful for any links.

Re: Virtual DOM is pure overhead (2018)

#109

Post by duxup » Tue, Jun 29, 2021, 2:50 PM UTC

jchw wrote: post #41

Svelte does something interesting in an innovative way. However, this article is overly focused on just one element of how React works. If your app is spending a significant amount of time doing virtual DOM diffs, then sure. The virtual DOM overhead is a problem. However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning. Their alternative is to add more complex compile…

>But, this is not how you sell something.

I feel that way about a lot of articles like this. I want to know what you do well, I don't want to hear someone complain about something else.

Sell me on what you do well and what that means for me.

I work in React a lot and I don't feel like I run into this “pure overhead” type concept in the way they describe it and thus this article makes me:

1. Wonder what they're doing in React that they feel this way.

2. The article quickly becomes much less relevant to whatever it is I'm thinking about.

Re: Virtual DOM is pure overhead (2018)

#110

Post by the__alchemist » Tue, Jun 29, 2021, 2:50 PM UTC

When I learned frontend web work and React years ago, I fell for the same "VDOM is fast!" hype, and assumed there was non-JS magic under the hood.

I eventually built a VDOM-based frontend WASM framework in Rust (Seed).

I now built frontends in HTML and CS, with no frameworks, and minimal, targeted JS code to manipulate the DOM directly; it's liberating, and much faster than both React and WASM/Rust.