Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

Post reply on HN
Print view View original

251–260 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#251

Post by cush »

macspoofing wrote: post #89
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…

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

> As a general claim, that is a bullshit claim.

How so? It improved on JQuery's performance ten-fold which was the "easy" way to webdev at the time.

Re: Virtual DOM is pure overhead (2018)

#252

Post by arcturus17 »

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.

I’ve experienced this (Reddit comes to mind) but I’m pretty sure it’s because it aggressively mounts/dismounts things on/from the real DOM.

In other words it virtualizes views (like when you have a 1000 row table and you only render rows 40-50), but this is not the same as DOM virtualization.

Re: Virtual DOM is pure overhead (2018)

#253

Post by arcturus17 »

recursive wrote: post #199
madeofpalk wrote: post #172

Earlier quoted context omitted.

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.

I’ve been coding in React for a few years and I’ve never seen anything like this. Bookmarking this so I can take a look tomorrow and also in case someone provides an answer.

Re: Virtual DOM is pure overhead (2018)

#254

Post by arcturus17 »

recursive wrote: post #239
WickyNilliams wrote: post #236

Earlier quoted context omitted.

I assume the issue here is that you are rendering a single nameInput instance in two places. This is definitely not idiomatic react and I can't ever think of seeing this in the wild. Just render two instances. If you want the value synced then it should be a controlled component, where the locked state is passed in as a prop.

> If you want the value synced then it should be a controlled component, where the locked state is passed in as a prop. This is the kind of stuff that's difficult for me to wrap my mind around. If I have to remember to "do it this way, but not that way", that's mental overhead. Especially when it's difficult to articulate exactly under what circumstances this problem occurs. Obviously, there are plenty of people that…

Everything you say is true for pretty much every technology?

Re: Virtual DOM is pure overhead (2018)

#255

Post by recursive »

arcturus17 wrote: post #254
recursive wrote: post #239

Earlier quoted context omitted.

> If you want the value synced then it should be a controlled component, where the locked state is passed in as a prop. This is the kind of stuff that's difficult for me to wrap my mind around. If I have to remember to "do it this way, but not that way", that's mental overhead. Especially when it's difficult to articulate exactly under what circumstances this problem occurs. Obviously, there are plenty of people that…

Everything you say is true for pretty much every technology?

No. Some technologies use paradigms that are much more natural to me. Of course, this will vary from person to person. I'm not saying that anyone should stop using react. I'm just saying that I find it to be difficult. Specifically more difficult than other technologies.

Re: Virtual DOM is pure overhead (2018)

#256

Post by recursive »

arcturus17 wrote: post #253
recursive wrote: post #199

Earlier quoted context omitted.

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.

I’ve been coding in React for a few years and I’ve never seen anything like this. Bookmarking this so I can take a look tomorrow and also in case someone provides an answer.

I seem to have a talent for coming up with things that shouldn't be, can't be, or are difficult to express in react. Note that I'm not particularly interested in other ways of writing this that would work. I now know several. I'm more interested in simple general rules that one could follow to stay out of trouble.

Re: Virtual DOM is pure overhead (2018)

#257

Post by acidbaseextract »

recursive wrote: post #199
madeofpalk wrote: post #172

Earlier quoted context omitted.

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.

Been working with React since 2014. That is the damndest thing ever, especially that it doesn't even throw a warning.

It seems like an identity confusion issue where the VDOM diff is ambiguous, and React resolves it in the "wrong" way. Adding keys to each `LabeledInput` resolves the issue, but I'm surprised that the runtime doesn't complain when you create the inputs without keys.

I wonder if this is why the checkbox that's checked moves, but stays in the same relative position (the second checkbox in the list): https://medium.com/@ryardley/react-hooks-not-magic-just-arra... or if it's just the ambiguous VDOM diff causing that.

Re: Virtual DOM is pure overhead (2018)

#258

Post by smrtinsert »

rendall wrote: post #212
rendall wrote: post #133

Earlier quoted context omitted.

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

Gah, at least it's not Salesforce. That year I spent in a Salesforce shop I earned gobs of money and nearly slit my wrists. I took the following year off. Learned to play ukulele. What a shitty platform. God bless the devs who thrive in it.

Looking at the future (sadly?). Most web apps are just shitty compilers that should be largely Metadata driven.

Re: Virtual DOM is pure overhead (2018)

#259

Post by kinjba11 »

mumblemumble wrote: post #200
paavohtl wrote: post #119

Earlier quoted context omitted.

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

You are correct. "Vanilla JS" is typically compared to React/Vue as a joke. As in "React.js is 2kb but Vanilla.js is 0kb and super lightweight".

"Vanilla C" doesn't have the same context as far as I'm aware. In the same spirit I could imagine a comparison for C would be along the lines of "you could use SDL (Simple DirectMedia Library) for your indie game dev, but why bother when you could use vanilla C (code Vulkan 3D graphics API directly)".

Re: Virtual DOM is pure overhead (2018)

#260

Post by rasz »

aidenn0 wrote: post #146
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'…

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…

Vivaldi browser is made using React. Frantic pointless UI DOM manipulations (deleting nodes just to recreate them back etc) are one of the main sources of performance degradation. https://news.ycombinator.com/item?id=27449736
Post reply on HN