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

211–220 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#211

Post by alserio »

peterhunt wrote: post #153

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time. Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular: 1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flo…

At least in my team the "constrained custom dsl" has been a net productivity win. The only people struggling for a bit were the ones used to react, since they tried to apply react solutions to every problem. It appears you need to unlearn a lot of react when using svelte, so I would argue that it's actually react that wants you do develop in a specific way. The same does not appear to be true for devs coming from other technologies. Other experiences may of course vary.

Re: Virtual DOM is pure overhead (2018)

#214

Post by c-smile »

ttfkam wrote: post #200
c-smile wrote: post #186

Earlier quoted context omitted.

In Sciter you do not need any preprocessor at all, not even JS in your HTML: div.beer { prototype: Beer url(/components/beer.js); } After that div.beer element will be instanceof Beer. In this case class Beer used as a [Web-alike] component.

1. I think you accidentally a tag 2. Your example would have atrocious load time implications for any non-trivial web page. Iterating the DOM through querySelectorAll to replace items at load time? Yikes! So apparently with Sciter you can either have minimal code or acceptable performance. Got it. Would rather have my cake and eat it too.

My sample is correct.

CSS prototype property is a Sciter specific extension.

When the engine computes styles it does [if needed] this (pseudocode):

   Object.setPrototypeOf(element, thatClass);
   element.componentDidMount();
on applied elements.

There is no "performance sacrifice" in case of handling prototype properties.

Prototypes are switchable if needed:

  div.beer { prototype: Beer url(...); }
  div.beer:hover { prototype: BeerHovered url(...); }

Re: Virtual DOM is pure overhead (2018)

#215

Post by MrOwnPut »

TheRealPomax wrote: post #167

Note that a virtual DOM is pure overhead if you already have a real DOM to work with . That's kind of the ignored superpower of a framework like React, which makes the virtual DOM the authority: there might be a DOM, but there also might not be. Whether the virtual DOM reflects to a real DOM, or native UI, or Qt, or an ASCII terminal interface, it doesn't care. This is also the part that most web devs have the hardes…

Why did I have to scroll this far down for the real answer?

This is the true power of the VDOM, to abstract the view from platforms.

Why be a web developer when you can be a cross-platform app developer?

That's why I don't use Svelte and other web SPA frameworks...

Re: Virtual DOM is pure overhead (2018)

#217

Post by fleddr »

Imagine being someone in the semiconductor industry reading this. You're at the absolute pinnacle of high-tech and are approaching the limits of material reality to realize a 20% faster CPU. It's a true super human accomplishment.

Software developers: well yes, 99% of the cycles I use are completely needless, but it's still plenty fast enough!

Which we justify with the idea that a framework like React is abstract, hence expressive and productive.

Excuse me? Abstract? React is absurdly low level.

25 years ago I was coding in Borland products. You visually drag you UI together. Link events with a click. Drag data sources and fields into UI to do two-way binding. Tooling chain? What tooling chain. There's a build and a run button. No weird text config files or CLI crap. And every setup is the same.

25 years later we're worrying about painting frames. We're pissing away impressive hardware performance whilst simultaneously not actually achieving abstraction. That's a double fail.

Re: Virtual DOM is pure overhead (2018)

#218

Post by horsawlarway »

ttfkam wrote: post #107
horsawlarway wrote: post #86

I'd argue this is essentially just an optimized (and therefore potentially more buggy) virtual dom. Svelte is being smart and skipping comparisons in the places it knows the result is static. That's nifty. But it also means you have to depend on svelte getting it right every time, in all scenarios. Long term - I think this is probably the right approach, but it feels very similar to the -03 c++ optimization flag: The…

Tell us you've never tried Svelte without actually saying you've never tried Svelte. You would have likely not said this if you had ever looked at Svelte-compiled JS. The amount of mutation is surprisingly small and easy to follow. Especially when coming from a world with JSX.

So what part of this statement do you disagree with?

> "it's building a vdom engine specific to your template"

Because that's... exactly what it's doing. It's doing it at compile time, and so yes - the amount of mutation in the output is small, which is not surprising at all because most templates are fairly static.

We can quibble over exactly what a VDOM is, but I don't really know that tracking only a subset of the DOM the app might change (aka: svelte) vs the entire DOM (aka: react) really matters. In both cases you need to map changes to DOM updates, Svelte is just being smarter about it.

Re: Virtual DOM is pure overhead (2018)

#219

Post by matvp »

szastamasta wrote: post #141
ttfkam wrote: post #103

Earlier quoted context omitted.

innerHTML doesn't preserve event handlers. So you're either reassigning event handlers over and over or relying on delegate handlers everywhere. And while your statement makes intuitive sense regarding performance, actual measurements show clearly that idiomatic Svelte (and other modern frameworks) routinely beat VDOM-based efforts handily in their idiomatic cases and often even when folks jump through the performanc…

From what I know React does not register event handlers on individual nodes, but rather on root component. Then it uses virtual events from it’s pool in your callbacks.

Side note, synthetic events are no longer pooled since React 17. There's no longer a noticable performance gain with more modern browsers nowadays.

Re: Virtual DOM is pure overhead (2018)

#220

Post by ttfkam »

c-smile wrote: post #214
ttfkam wrote: post #200

Earlier quoted context omitted.

1. I think you accidentally a tag 2. Your example would have atrocious load time implications for any non-trivial web page. Iterating the DOM through querySelectorAll to replace items at load time? Yikes! So apparently with Sciter you can either have minimal code or acceptable performance. Got it. Would rather have my cake and eat it too.

My sample is correct. CSS prototype property is a Sciter specific extension. When the engine computes styles it does [if needed] this (pseudocode): Object.setPrototypeOf(element, thatClass); element.componentDidMount(); on applied elements. There is no "performance sacrifice" in case of handling prototype properties. Prototypes are switchable if needed: div.beer { prototype: Beer url(...); } div.beer:hover { prototyp…

Oh geez. It's Internet Explorer CSS Behaviors all over again.

"Those who do not learn from the past…"

Post reply on HN