Live data from Hacker News

Virtual DOM is pure overhead (2018)

svelte.dev

61–70 of 293 posts

Re: Virtual DOM is pure overhead (2018)

#61
post #11

For 95% of apps, Svelte's custom syntax is pure cognitive overhead making little difference to the performance of the app.

For me, trying to make sense of how React's reconciler matches hook invocations to component instances is pure cognitive overhead. Other people don't seem to have this problem. But trying to accomplish anything in React is arduous for me, particularly with function components and hooks. Class components seem a little more obvious.

Is it possible to just not think about it? Or is that easier said than done?

Re: Virtual DOM is pure overhead (2018)

#62
This is one of the reasons I am so into Lit (lit.dev). The web platform has changed so much the past few years, vDOM made a ton a sense back when React first launched and even for many years after that. It makes a lot less sense in 2021.

I would even make the same argument for JSX itself. Once again JS now have template literals built into it.

For anyone coming from a React background check out this code lab to see the difference: https://codelabs.developers.google.com/codelabs/lit-2-for-re...

Re: Virtual DOM is pure overhead (2018)

#63
I’m not a JS frameworks expert, too much churn to keep up. I learned Angular 2+ a few years ago and found it to be a bit heavy weight. Thinking of learning Vue 3 now. Svelte looks interesting though. What I am hoping for long term is that the JS/CSS/HTML5 stack will be mature enough and have enough batteries included that I can just write apps using the “standard library” with minimal external libraries. Is that the direction things are going?

Re: Virtual DOM is pure overhead (2018)

#64

I feel like nobody is asking: what is the point of all this performance chasing with frontend frameworks? You might get a millisecond here or there. So what? In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application. It's almost always some type of network communication issue, be it the database stalling or static assets not being served. Where JS rendering mi…

> In my experience it has never, ever been the JS rendering layer which has caused unresponsiveness in an application.

Implemented a undo/redo stack on top of Vuex once that worked on some very large data structures.

Got unresponsiveness after only ~3 changes to the data. Purely due to how Vuex checks state for changes. No network, no database; purely in the frontend client.

Ended up needing to freeze the state as I pushed it into the Vuex store, so Vuex wouldn't check previously pushed state for changes.

My point is, there are multiple places where, if you are building an app of scale, you can run into client performance issues.

Re: Virtual DOM is pure overhead (2018)

#65
post #20

While this may have been true previously, React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames, to achieve perceptual improvements over synchronous DOM updates. Svelte’s AOT compilation approach, I believe, is limited in these kinds of time-spanning deferrals, though I’d love to be proven wrong! https://reactjs.org/docs/concurrent-mode-intro.html

> React’s new concurrent mode can leverage a Virtual DOM to split actual DOM updates over animation frames

That's just cheating though, isn't it? And not in a good way. If you smear your DOM update over consecutive frames, you can maybe cram in 2-4x more operations in there before the user starts noticing. Past this point, a smeared update starts having design implications - things that should happen simultaneously now happen sequentially. Not to mention, application starts to feel heavy.

Re: Virtual DOM is pure overhead (2018)

#66

I will probably get downvoted as I am in minority who still believe Server Side Rendering is the best approach for most of the web with exceptions to some websites that require Single Page App functionality. I still think web would be best if you do SSR and then replace HTML DOM elements using frameworks like Stimulus Reflex or Hotwire. For millisecond interactivity you may want to write JS in a framework like Stimul…

Most of the web can and should be static HTML and CSS.

Re: Virtual DOM is pure overhead (2018)

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

> this article categorizes virtual DOM as a “meme” that is “pure overhead” that only wins against a “strawman” The part that I think the article misses is that VDOM is just an implementation detail of React. No one actually really cares about it, and its not the reason why people use React.

    It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones.

    But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.

Re: Virtual DOM is pure overhead (2018)

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

[deleted]

Re: Virtual DOM is pure overhead (2018)

#69

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…

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's not necessary now, there's not necessarily any escape. The problem with complex tech stacks is that, for a variety of technical and social reasons, it's much easier to add to them than it is to take away. You can't necessarily incrementally roll back any of the bits of an existing React-based site; such an effort is liable to spiral into a complete rewrite. It's relatively easy, though, to incrementally add new things in order to paper over whatever's bugging you at the moment.

The social story is similar. Coming from a position of knowing very little, the effort for me to learn the vanilla JS way of doing things is roughly similar to the effort to learn the React way of doing things. But, if I were already invested in the React ecosystem, that wouldn't be the case. I wouldn't just have to learn new tooling, I'd also have to re-learn my entire way of thinking about how to architect a webpage. Realistically, you can't, all else being equal, justify a radical re-tooling in order to achieve an incremental benefit like that.

Re: Virtual DOM is pure overhead (2018)

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

Performance is not a problem for the most developers, as long as the app runs smooth.

React gave us not a better programming model, it gave us an other programming model. In some cases template based enignes are better than JSX, but that discussion has nothing todo with Svelte or React.

React boomed cause at that time everybody has enough of bloated frameworks and with JSX you had a wonderfull thing to tinker code... thats what developers like, tinker all the day complex bloated code. Why made it easy, when you can have it complex? ;-) And it came from well known Facebook, thats it, nothing more.

I rememnber the day when everybody was shouting, Redux is the best thing every ;) And now "hooks" Really?

Post reply on HN