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

141–150 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#141

Post by szastamasta »

ttfkam wrote: post #103
c-smile wrote: post #30

Yes and no. Having implemented virtual DOM natively in Sciter (1), here are my findings: In conventional browsers the fastest DOM population method is element.innerHTML = ... The reason is that element.innerHTML works transactionally: Lock updates -> parse and populate DOM -> verify DOM integrity -> unlock updates and update rendering tree. While any "manual" DOM population using Web DOM API methods like appendChild(…

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.

Re: Virtual DOM is pure overhead (2018)

#142

Post by megaman821 »

mhink wrote: post #132
c-smile wrote: post #109

Earlier quoted context omitted.

This: element.append([array of Elements]); is in magnitude of times faster than for(const el of [array of Elements]) element.appendChild(el); so yes, it helps to improve situation. But think about updates like this: element.patch( 1}>There {n > 1? "are": "is"} {n} bottle{n > 1? "s": ""} of beer on the wall ); Here you need to update (or not) as the attribute as text nodes. You need some transactional mutation mechani…

Oddly enough, this doesn't seem to be accurate: check out https://jsbench.me/02l63eic9j/1 . I also would have sworn up and down that using a DocumentFragment would be loads faster than both, but it doesn't seem to be the case. I wonder why that is.

https://twitter.com/jaffathecake/status/1552242561313546241?...

Re: Virtual DOM is pure overhead (2018)

#143

Post by taftster »

dangoor wrote: post #136
divan wrote: post #128

Is there any discussion in webdev community whether using typesetting engine from 80s is even a good idea for modern performant UI apps? Or it's just taken for granted and never questioned?

I don't think that perspective is fair to modern browser engines. The additions of flexbox and grid layouts took them beyond just typesetting, I think (not to mention all of the work on JS engines, providing APIs for a whole bunch more device functionality, etc.) So it's true that there's still a "typesetting engine from the 80s" in there, but there's also a powerful layer of app functionality built-in as well. It's…

Right. It's been discussed before, but the web browser is one of the greatest examples of "write once, run anywhere" in terms of the markup that is HTML. If the evolution had happened differently, maybe we'd be all be using Java applets or Flash applications instead. I believe HTML/browser is superior, but I wonder where other platforms would have evolved to.

Re: Virtual DOM is pure overhead (2018)

#145

Post by ironmagma »

ttfkam wrote: post #120
ironmagma wrote: post #101

And having a custom JS compiler isn't pure overhead?

Are you calling a C compiler overhead as well? Ahead of time compilation is not runtime overhead, and for users of the web, runtime and network latency are all that matters with regard to the perception of speed.

Mental overhead matters much more than performance overhead to most applications. The whole plot of JS is that it’s easy enough to work with that it overpowers any performance limitations. Svelte invents a completely new execution model for JS which adds overhead.

Re: Virtual DOM is pure overhead (2018)

#146

Post by c-smile »

mhink wrote: post #132
c-smile wrote: post #109

Earlier quoted context omitted.

This: element.append([array of Elements]); is in magnitude of times faster than for(const el of [array of Elements]) element.appendChild(el); so yes, it helps to improve situation. But think about updates like this: element.patch( 1}>There {n > 1? "are": "is"} {n} bottle{n > 1? "s": ""} of beer on the wall ); Here you need to update (or not) as the attribute as text nodes. You need some transactional mutation mechani…

Oddly enough, this doesn't seem to be accurate: check out https://jsbench.me/02l63eic9j/1 . I also would have sworn up and down that using a DocumentFragment would be loads faster than both, but it doesn't seem to be the case. I wonder why that is.

> this doesn't seem to be accurate

It is pretty accurate here, case #3 is significantly (almost two times) slower than case #1.

Re: Virtual DOM is pure overhead (2018)

#147

Post by mmis1000 »

harel wrote: post #11

Svelte is great. React is great. X, Y and Z are also great. And you know what they all share as well? Speed. They are all fast . Definitely fast enough for 99% of all uses cases if not more. The benchmarks they all provide are just benchmarks. I treat them like I treat car range reports by the car makers. I personally use react because I know it well, and it allows me super speedy development cycle once all the base…

React is fast in the sense it eat tons of computation power without lagging the ui. In my opinion, this is a dead end. They should really try to reduce the actual computation power required to render the ui. The growing rate of cpu speed is stalled. There already isn't too much room for it.

And what about user with a low end Android machine? Not lagging the ui isn't helpful here. Because it still need seconds to render the whole thing.

Re: Virtual DOM is pure overhead (2018)

#148

Post by postalrat »

scotty79 wrote: post #83
spankalee wrote: post #65

Earlier quoted context omitted.

vdom is overhead server-side too. When rendering HTML on the server you really want to stream longer pre-allocated strings as much as possible. The serialization overhead of converting many small objects to individual HTML tags shows up in profiles. And when you want low latency and the ability to handle high loads, it matters.

Can we please go back to templates compiled directly to php files that just get executed?

Why php and not JavaScript?

Re: Virtual DOM is pure overhead (2018)

#150

Post by stillkicking »

PaulHoule wrote: post #138
TurningCanadian wrote: post #113

Earlier quoted context omitted.

> React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways. The built-in React way of doing that is with context.

A classic example of: "you had one problem, now you have ten problems". That's fine if you aren't writing any unit tests or trying to fix bugs with the debugger. If context are in use you might have some 'simple' system with 10 components that shows 150 components in the React component viewer most of which are worthless context blocks that are just there to waste your attention and probably the CPU and memory of you…

>React doesn't provide a systematic answer for handling state in apps if data is flowing up, down and sideways

So let's first back up and recognize that this earlier statement was flat out wrong. React does provide a systematic answer for this.

Second, not only does it have a systematic answer, but it memoizes quite well because React will not re-render children if the `children` prop is identical to the previous render, even if you don't use `memo()`. This means it is quite cheap to have context providers update, even if you nest 2 or 3 of them.

The big issue with React in my experience is just that developers are lazy af and will stubbornly refuse to read even the tersest of docs even if they are encountering a new paradigm, like declarative and reactive UI. The result is a giant spaghetti mess of their own creation, which they then blame the framework for.

You can make React fast and you can keep it clean, all you have to do is topologically sort your data by the frequency of how quickly it changes. That's it. That's the trick.

Post reply on HN