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

41–50 of 344 posts

Re: Virtual DOM is pure overhead (2018)

#41

Post by dsissitka »

ng12 wrote: post #23

I keep hearing this and find it really hard to care about. Runtime performance is not a bottleneck for me. Once in a blue moon I'll have to optimize a React component with shouldComponentUpdate but otherwise I have no performance concerns even on old browsers. There are other characteristics that are very, very important like build size. VDOM is not worth thinking about. Honestly I don't understand Svelte. It sounds…

If you value build size you might want to take another look at Svelte. Build size is one of its strengths. For example, the Svelte implementation of RealWorld is roughly 10% of the size of the React/MobX implementation:

https://medium.freecodecamp.org/a-realworld-comparison-of-fr...

Edit: Confused the React/Redux implementation with the React/MobX implementation the first time around.

Re: Virtual DOM is pure overhead (2018)

#43

Post by spankalee »

Waterluvian wrote: post #22
kabes wrote: post #16

Earlier quoted context omitted.

Virtual dom is an implementation decision for performance a developer shouldn't even be very aware of. The main upside to react is that it has a huge ecosystem.

You should at least be aware of the gist, lest you obsess over premature optimization. 1. Changes to the DOM cost a ton more than executing JS code. 2. So don't feel too bad when a render() gets called that doesn't change anything because the virtual DOM swallows that.

> 1. Changes to the DOM cost a ton more than executing JS code.

The point of the article, and of the performance problems that people actually have with React is that this might be true for a small number of JS operations, but that

1) Tree diffs are computationally complex operations that add up for real-sized apps 2) The diff is actually unnecessary if you simply take into account the structure of templates, so diffs are pure overhead.

So _do_ feel bad when you have a no-op render() in React at least, because the resulting VDOM diff just chewed up CPU and battery for no reason.

Re: Virtual DOM is pure overhead (2018)

#44

Post by munchbunny »

jordache wrote: post #27
Lowkeyloki wrote: post #11

First, I think anyone using React solely because of the virtual DOM implementation is largely missing the point. IMHO, the real win of React is the functional and composable way components can be designed and implemented. Second, no disrespect to Svelte, but I think there's a huge trade-off between the React approach and the Svelte approach that developers should be aware of. React is a pretty unopinionated library,…

>functional and composable way components can be designed and implemented. Ughh.. that's the point of all modern FE frameworks... You are putting that description on a pedestal as if that is a unique property of React.

Composable, yes, but functional as in functional programming, no.

Re: Virtual DOM is pure overhead (2018)

#45

Post by spankalee »

ec109685 wrote: post #35
spankalee wrote: post #5

This is absolutely true. Virtual DOM diffs do a huge amount of unneeded work because in the vast majority of cases a renderer does not need to morph between two arbitrary DOM trees, it needs to update a DOM tree according to a predefined structure, and the developer has already described this structure in their template code! A large portion of JSX expressions are static, and renderers should never waste the time to…

One thing nice about React is that it can take care of quoting for you depending on the method call the jsx template translates into (attribute, value, element name). String templates doesn’t have that nice property.

Can you explain that more?

I'm not sure what you're saying is true with lit-html. You don't have to quote attributes with single expressions.

    html``
is perfectly fine.

Re: Virtual DOM is pure overhead (2018)

#47

Post by keymone »

spankalee wrote: post #13
thoman23 wrote: post #12

2 things I'm not seeing in the article or in the comments so far: 1) The virtual DOM is an abstraction that allows rendering to multiple view implementations. The virtual DOM can be rendered to the browser, native phone UI, or to the desktop. 2) The virtual DOM can, and should, be built with immutable objects which enables very quick reference checks during the change detection cycle.

There are other ways to represent a UI as data that don't require a diff. JSX's default compiler output throws away information needed to do efficient updates, and instead requires diffing the entire old and new trees. Immutable objects may optimize for checking for data changes, but only if you do that, as in shouldComponentUpdate or checking inside render(). They don't optimize the _diff_, which is done against the…

How often is diff done against the DOM? My understanding is that it’s done against last valid vDOM instead.

Re: Virtual DOM is pure overhead (2018)

#48

Post by Lx1oG-AWb6h_ZG0 »

Dan Abramov has a great thread about this here: https://mobile.twitter.com/dan_abramov/status/11209717954258.... In particular, I find this argument really persuasive:

> Time slicing keeps React responsive while it runs your code. Your code isn’t just DOM updates or “diffing”. It’s any JS logic you do in your components! Sometimes you gotta calculate things. No framework can magically speed up arbitrary code.

In my experience, as your app grows, the amount of time you spend on dom reconciliation becomes negligible compared to your own business logic. In this case, having a framework like React (especially with concurrent mode) will really help improve perceived user experience over a naive compiled implementation.

Re: Virtual DOM is pure overhead (2018)

#49

Post by namelosw »

Rusky wrote: post #30
namelosw wrote: post #18

I thought this was well known years ago. A better description for VDOM should be 'It's not fast, and is not slow either'. But frankly, what I see in virtual DOM is not about speed. It's a declarative interface, an abstraction. It's more like a blueprint that's easier to interpret across different environments like React Native, WebGL. Even if you don't need any of these cross-platform benefits it's still good for tes…

The point of the article is that you can get that same declarative interface at much lower cost, with a more efficient implementation.

I'm not sure if it's still an 'interface' since it's compiling another language to imperative code which operates DOM API. So it requires other platforms implements a similar imperative API surface as DOM.

Re: Virtual DOM is pure overhead (2018)

#50

Post by spankalee »

keymone wrote: post #47
spankalee wrote: post #13

Earlier quoted context omitted.

There are other ways to represent a UI as data that don't require a diff. JSX's default compiler output throws away information needed to do efficient updates, and instead requires diffing the entire old and new trees. Immutable objects may optimize for checking for data changes, but only if you do that, as in shouldComponentUpdate or checking inside render(). They don't optimize the _diff_, which is done against the…

How often is diff done against the DOM? My understanding is that it’s done against last valid vDOM instead.

Sorry, you're correct for React, and for most VDOMs, though some do diff against the DOM.

The point is that the diff isn't sped up by using immutable data. The app data is only used to generate the vdom tree, and the diff is after that.

Post reply on HN