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

Re: Virtual DOM is pure overhead (2018)

#141

Post by the__alchemist » Tue, Jun 29, 2021, 3:33 PM UTC

ehnto wrote: post #138

the__alchemist wrote: post #110

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.

It's crazy how quickly frontend UI frameworks became the standard approach. They're not necessary in so many instances where they are used. I also found it pretty comical when server side rendering became a hot topic, like duh guys, that's what we were doing first! Did you forget? Anyway, it's not that frontend UI frameworks are bad, it's more that pragmatism gets thrown out the window so quickly.

It feels like we were coasting on a mentality of "Computation is cheap; We're in post-performance-scarcity era; Performance doesn't matter since computers are fast". -- Ignoring the reality that responsiveness is critical to user experience.

Re: Virtual DOM is pure overhead (2018)

#142

Post by jcuenod » Tue, Jun 29, 2021, 3:34 PM UTC

KaoruAoiShiho wrote: post #22

Svelte is so 2020, the new hotness is SolidJS. https://dev.to/ryansolid/solidjs-official-release-the-long-r...

Honestly, SolidJS is one of the most exciting options on the horizon. The creator wrote the vanillajs implementation for the frontend framework benchmarks so he really knows a lot about the performance implications of implementation details. The great thing about Solid is that it's a lot closer to react with hooks and jsx (I feel like Svelte is learning too much non-js stuff). The problem is that it also has its gotchas. It's much "smarter" than react about re-rendering, which means that it memoizes nodes all over the place and doesn't rerender the entire tree and diff all the time. Instead, it's only rerendering the node that changed (and not even the children of that node unless you set up the children correctly—gotcha). But look at the benchmarks... it's solid!

I asked Rich Harris (author of Svelte) this: https://twitter.com/jamescuenod/status/1326747369480871941?s...

Ryan Carniato (author of Solid) makes some comparisons to Svelte here: https://dev.to/ryansolid/5-ways-solidjs-differs-from-other-j... and also here: https://github.com/solidjs/solid/blob/809fd5b8683e6f8c338961...

Re: Virtual DOM is pure overhead (2018)

#143

Post by iaml » Tue, Jun 29, 2021, 3:35 PM UTC

sopooneo wrote: post #108

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 l…

From my limited experience with c#/xaml and swift apps, it's MVC/MVVM mostly, although apple is moving towards react-like swiftui.

Re: Virtual DOM is pure overhead (2018)

#144

Post by handrous » Tue, Jun 29, 2021, 3:40 PM UTC

ubercore wrote: post #116

macspoofing wrote: post #89

Earlier quoted context omitted.

>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. Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because…

I seem to remember that when React was first introduced, DOM mutations _were_ very expensive. I was under the impression that a lot of optimization was done in reaction to, err, React and similar frameworks?

Tons of DOM mutations in a hot loop are slow.

One DOM mutation is faster than one VDOM-to-DOM flow, though, of course, since the latter's doing the same thing plus more. The latter also uses a lot more memory, and keeps it around indefinitely unless you want to risk performance-killing deallocs and allocs later (I'm making some assumptions there—I'd expect a typical VDOM implementation's memory is rarely released, since re-building that data structure would be high cost if you need it again and largely defeat the purpose).

VDOM's also pure JS in the typical implementation, which is going to tend to be slower and (much) less memory efficient than getting the fuck out of JS and into the browser's C++ or Rust or whatever, ASAP (React's, for instance, is a big ol' tree of JS objects, AFAIK).

If you're often modifying or inserting 10,000 elements per update and can't be bothered to somehow batch those yourself, virtual DOM is probably a performance win. If the count is typically more like 1-10, it's probably overhead. In between, shit, I dunno, benchmark it.

Re: Virtual DOM is pure overhead (2018)

#145

Post by jakelazaroff » Tue, Jun 29, 2021, 3:41 PM UTC

ElViajero wrote: post #19

The web stack, from tunneling thru HTTP to the JavaScript language itself, is a very interesting case study. I think that many decisions, like creating a virtual DOM, make a lot of sense in isolation. But, if you look at the complete ecosystem, no sane human being would have ever designed anything like that. Maybe, the Virtual DOM is pure overhead if you look at the complete system, but: 1. It was reasonable at the t…

At my job, we have a desktop app that uses HTTP and WebSockets. We compile it into WASM for the browser. My side project is a single page app. My personal website static HTML and CSS, with almost no JavaScript at all.

I think that the independence of various parts of the web stack is actually a strength, not a weakness. Because you don't need the complete ecosystem — you can pick and choose which parts to use, mostly without compromise.

Re: Virtual DOM is pure overhead (2018)

#146

Post by aidenn0 » Tue, Jun 29, 2021, 3:45 PM UTC

mumblemumble wrote: post #124

macspoofing wrote: post #89

Earlier quoted context omitted.

>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. Svelte's main point is that the performance claims of frameworks like React are just bullshit marketing-speak. That I agree with it. The value of JS UI frameworks in general, isn't in performance, but rather to provide a "declarative, state-driven UI development" because…

> React tried to argue that direct DOM mutations are expensive and that using virtual DOM will yield more performance. As a general claim, that is a bullshit claim. My impression is that it's the kind of claim that's actually true in general, despite being false in all the particulars. Like, every step of the way, yes, virtual DOM adds extra steps to the process, and they have a cost. But, in the big picture, if you'…

I wrote a react application and VDOM overhead was so high that I had to cut down what parts of the UI were rendered to just what was on-screen at any given time. Performance was just barely okay on a desktop and completely unusable on an Android phone.

Not using react made everything work amazingly fine. Granted this was an application with fairly low amounts of DOM manipulation (popup things when the user clicks on stuff, some lists that elements can be added/removed to/from), but those sorts of things seem fairly typical.

I wanted to use React because the code was so much cleaner and concise, but it was just way too slow.

Re: Virtual DOM is pure overhead (2018)

#147

Post by handrous » Tue, Jun 29, 2021, 3:47 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.

Whichever framework has a prominent PR lead is "safe" to choose. If it's bad or breaks or whatever, it's not your fault, it's... I dunno, the hive-mind's, I guess. It's the "no-one ever got fired for buying IBM" factor. Whether it's actually any good or the best fit for the case it's been selected for, is very much secondary.

Re: Virtual DOM is pure overhead (2018)

#148

Post by yohannparis » Tue, Jun 29, 2021, 3:49 PM UTC

rendall wrote: post #133

KronisLV wrote: post #105

Earlier quoted context omitted.

> 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 befor…

> With React/Angular/Vue you're given a stable base upon which to build new components and logic Oh you sweet summer child. Wait until you see the multilayered horror of devs insisting on styled components because they never spent the time to learn the specificity rules of CSS; their grabbing at lowdash debounce or react-virtual because they don't have the confidence to build a leaner version themselves; suggesting t…

I agree 100%.

The number of times someone told me they prefer using Bootstrap classnames while using CSS when they bootstrap does not provide a classname for it... My front-end heart sinks!

Re: Virtual DOM is pure overhead (2018)

#149

Post by moritzwarhier » Tue, Jun 29, 2021, 3:49 PM UTC

px43 wrote: post #103

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.

Never had this problem really (doesn't mean that it doesn not exist). Is shadow DOM a thing outside of SVGs? For sure it's not used by React, Vue etc. MDN is telling me that the upcoming Web component spec uses it though, so maybe libraries like LitElement use it too?

Sites using React or Vue all seem to be searchable using standard CTRL-F for me.

Re: Virtual DOM is pure overhead (2018)

#150

Post by darepublic » Tue, Jun 29, 2021, 3: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…

>However, saying it’s pure overhead and then not qualifying how much is a catastrophic failure of reasoning.

a more catastrophic failure of reasoning, that is far more prevalent, is not understanding that virtual DOM is overhead on top of the regular DOM, not some magic fairy dust invented by facebook geniuses that just makes the web better (tm) because you are a dev whose first exposure to web development was via a React tutorial where you built some clone as it held your hand every step of the way, and now you are loosed into the jungle of problems in the wild ready to crush the spirits of those old tired jquery devs. bwahahahaha.