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

Re: Virtual DOM is pure overhead (2018)

#191

Post by RivieraKid » Tue, Jun 29, 2021, 5:24 PM UTC

progx wrote: post #84

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…

That is true, Svelte did not have a big benefit over React, so no need to change. And i use Svelte. When you start or build a new product/team and can freely choose which Framework you want to use, you can have a look at Svelte. For our company Svelte is easier to use, it has (in our opinion) less bloated code (e.g. state handling) in our app as React or Vue (which we used before). BUT, Svelte has other problems, esp…

> BUT, Svelte has other problems, especially when you heavily use dynamic components, which are easier to handle in Vue or React.

Do you have an example?

Re: Virtual DOM is pure overhead (2018)

#192

Post by slumdev » Tue, Jun 29, 2021, 5:26 PM UTC

blacktriangle wrote: post #158

slumdev wrote: post #157

Earlier quoted context omitted.

Browsers support HTML and JS (and a few other things not relevant to this point). Neither HTML or JS on its own will do what you're describing. HTML doesn't allow binding to a data source. JS doesn't allow you to write HTML declaratively. So, people build abstractions. If an abstraction ever became popular enough and futureproof enough, there could be a case for supporting it natively. But I don't know of anything th…

Natively no, but writing some JS code that will take an array of objects and turn it into a DocumentFragment is a trivial exercise. And once you're representing your HTML as data, looping and data binding are trivial.

You're right. But how often do you want to rewrite that code? It may be worth accepting a few -isms (and the associated performance hit) in order to be able to write something like this instead of having to bang out the imperative version:

Re: Virtual DOM is pure overhead (2018)

#193

Post by imbnwa » Tue, Jun 29, 2021, 5:27 PM UTC

darepublic wrote: post #153

mumblemumble wrote: post #124

Earlier quoted context omitted.

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

no its not wrong to criticize the culture in web development of salivating over every new framework. And rebuilding company code in hyped up framework X without pausing to understand the problem you're trying to solve and why the current glob of code is so damn buggy. I see experienced web devs, if not fall for this mistake themselves, happily prop it up to management every damn day across many companies. I've read t…

> As someone who has written fiddly DOM manipulation code, no its not my preference over React JSX, but having the level of understanding TO write surgical DOM manip code should be a basic floor of ability for any web developer using react or otherwise imo.

As a bootcamper who came from a philosophy background to frontend, you will be surprised how many 15 year "veterans" in web dev can't write coherent code without a framework, couldn't tell you how designing data one way or another impacts their code design, and when you confront them on this, bring it to their attention, they find any which way to dismiss the problem with "do we really need that"/"why do we need that" as if their's virtue in pretending to be the Product team in the face of shoddy engineering. Enterprise agile largely enable this fairly low floor. Engineers can handwaive anything in the name of the holy right now.

Re: Virtual DOM is pure overhead (2018)

#194

Post by chrishtr » Tue, Jun 29, 2021, 5:30 PM UTC

macspoofing wrote: post #136

ubercore wrote: post #116

Earlier quoted context omitted.

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?

>I seem to remember that when React was first introduced, DOM mutations _were_ very expensive. Not really. Rendering was always a heavily optimized area. The DOM, by the way, is also an in-memory data-structure, and can also be clever on how it batches draw commands to the hardware (GPU or otherwise). I was always skeptical of the performance benefits of frameworks like React for that reason. The big benefit of UI fr…

See https://developer.chrome.com/blog/renderingng/ for some idea of the scale of investment being made.

Re: Virtual DOM is pure overhead (2018)

#195

Post by lhorie » Tue, Jun 29, 2021, 5:36 PM UTC

protonimitate wrote: post #74

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…

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

The scale argument is really just a chicken-and-egg thing. A few years ago, people were saying the same thing about how Vue wasn't "proven" at scale. But these days there are sizable teams using Vue just fine. The entire point of the components-first paradigm is that you can scale a UI fractally.

Large teams were using jQuery back in the day, with none of that HMR prettier-on-save Redux devtools fanciness. There's nothing inherently "unscalable" about the technology, especially now that most frameworks more or less use the same framework design paradigms.

> nothing about has convinced me to lead a project/team towards picking that over React,

This is just a cost of switching consideration. For better or for worse, first movers advantage is a thing. You're also not likely to switch from date-fns to dayjs or postgresql to mysql because you are invested into your choice of technologies, even though each pair might in theory be perfectly interchangeable.

Re: Virtual DOM is pure overhead (2018)

#196

Post by eagsalazar2 » Tue, Jun 29, 2021, 5:38 PM UTC

macspoofing wrote: post #182

eagsalazar2 wrote: post #177

Earlier quoted context omitted.

>> That Svelte isn't popular is because some frameworks get popular and go viral and others don't. That's it. This is complete and utter nonsense. Were you programming seriously before React? There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very…

>This is complete and utter nonsense. Were you programming seriously before React? Indeed I was. >There were like 50 popular frameworks all competing with each other and no one framework dominated. React has completely taken over because it provided a dramatically better developer experience and solved a lot of hard and very real problems. I'm not saying React isn't a good framework, it is perfectly nice, though I th…

I'm not sure I'd agree that when React took over, Angular was a perfectly fine framework. I mean, what happened with React was actually very unusual and remains very unusual. It took over. There is this popular and snarky notion that js devs are constantly chasing every shiny thing but that is exactly the opposite of what has happened over the last several years with React. Instead I'd argue that js devs were nomads prior to React because none of the existing solutions were solving the big problems they had. Not because they are ADD fad chasers. Also I don't remember seeing React "marketing" any more than any other framework. Of course when Google or FB or any other major player gets behind a framework, we take notice, but that doesn't have anything to do with why React took off. It won because frp in a FE framework with the Flux pattern was a total game changer and made FE development awesome for the first time ever (well since Flex, I'll take your word for it since that is even before my time (I cut my FE teeth on jquery and Dojo!))

Re: Virtual DOM is pure overhead (2018)

#197

Post by arxpoetica » Tue, Jun 29, 2021, 5:43 PM UTC

Panther34543 wrote: post #168

I spent part of last Saturday going through the Svelte tutorial, and I really liked the framework. I then was looking at recommendations for building fully functional web apps, and the official recommendation was to use "Svelte Kit". I began the tutorial for that, and was surprised at how the philosophy of that framework seemed to completely contradict the core Svelte framework. It was extremely odd and unappealing,…

You absolutely 100% do not have to use Svelte Kit.

Svelte Kit is just the equivalent of (an opinionated) Next.js, Gatsyby, or Nuxt.js framework. Those frameworks are also incredibly opinionated on purpose.

Re: Virtual DOM is pure overhead (2018)

#198

Post by tonymet » Tue, Jun 29, 2021, 5:46 PM UTC

Is there a good benchmark showing the number of dom nodes vs ui latency? React works well for few dom elements but suffers in messaging apps where dom count and dependency graph are large and complex

Re: Virtual DOM is pure overhead (2018)

#199

Post by recursive » Tue, Jun 29, 2021, 5:51 PM UTC

madeofpalk wrote: post #172

recursive wrote: post #156

Earlier quoted context omitted.

Usually it just works. But, even following the "Rules of Hooks" ( https://reactjs.org/docs/hooks-rules.html ), I managed to write some code where the state that belonged to one component ended up in its adjacent sibling. When that happened, I really wasn't sure what to do other than go on a deep react dive. It's not clear how to debug stuff like that. I came to realize that I had confused the reconciler. The fix is b…

How did this happen? I've never seen this in practice if you weren't doing something "obviously" wrong.

Here's a minimal-ish repro of the issue I ran in to. It's totally possible that I'm doing something "obviously" wrong. However, I've spent more than a couple of hours reading through docs trying to figure out what it is. I'm not seeing it.

https://codepen.io/recursive/pen/XWMLWBZ

If you could point to anything in the docs that I'm missing, I'd genuinely appreciate it.

Re: Virtual DOM is pure overhead (2018)

#200

Post by mumblemumble » Tue, Jun 29, 2021, 5:51 PM UTC

paavohtl wrote: post #119

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

Pedantry time: there is no such thing as a vanilla JS way of building web applications, in the same way there is no vanilla C way of writing compilers. JavaScript as a language does not concern itself with web browsers - that's the responsibility of the DOM API. But even ignoring that, there is no standardized or widely adopted way to build interactive web applications without frameworks.

I'm new here, so maybe I'm misunderstanding some Web developer jargon? I had assumed that, when someone says "vanilla JS" in a web development context, it was understood to mean, "the core language plus the standard browser APIs."

"Vanilla C" maybe isn't a perfect analogy because the language and standard library are both covered by the same spec. But I suppose I would argue that it means, "Just C and its standard library, not including, for example, glibc extras." I don't know what a C equivalent to React would be. Maybe a better analogy would be "Vanilla Java", with the intent being to imply that you aren't using Spring?