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

131–140 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#131

Post by wruza »

napkin wrote: post #48
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…

Saying they're fast is a relative statement. I primarily use an MNT Reform. On 4x ARM Cortex-A53 cores, most modern web apps are slow (the new reddit interface, the new gmail, virtually every airline booking UI, my music player of choice, etc.). I hate the web.

Do you believe that these sites would be fast if built with other non-SPA or non-“modern” libraries?

It’s like thinking that a faster car or a bicycle could be faster in a city with bad traffic light logistics. All of Svelte, React, Vue, jQuery, DOM are equally visibly fast until you attach these 10 megabytes of /metrics-n-spyware/**/*.js.

Re: Virtual DOM is pure overhead (2018)

#132

Post by mhink »

c-smile wrote: post #109
runarberg wrote: post #76

Earlier quoted context omitted.

Is this still the case with the newer transactional methods like Element.append(), Element.before(), and DocumentFragment? When I manipulate the DOM I try to create the entire structure in a fragment and the use .append(...) only once.

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.

Re: Virtual DOM is pure overhead (2018)

#133

Post by sroussey »

SigmundA wrote: post #66
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(…

Just have a suspendLayout resumeLayout / beginUpdate endUpdate method like Winforms surprised doesn't exist after all these years

layout is suspended automatically. Unless you query the dom for something, in which case you can get lots of thrashing. For example, you don’t want to add some dom elements, then get their height/width as that will force the layout. And don’t do that in a loop! Last I looked, addjng/removing dom elements only schedules the layout and repaint. Things have gotten more multithreaded since I looked at browser code for this, but I doubt they would make a performance regression here.

Re: Virtual DOM is pure overhead (2018)

#134

Post by mmis1000 »

spankalee wrote: post #17

The key observation about HTML templates is that usually large portions of them don't change with new data. There is static content, and even with lots of dynamic bindings they're tied together in a static structure. So the vdom approach of processing all the static parts of a template during a diff is just extremely wasteful, especially for fairly common cases like conditionally rendering a node before some static c…

> So the vdom approach of processing all the static parts of a template during a diff is just extremely wasteful, especially for fairly common cases like conditionally rendering a node before some static content.

Vue 3 already just render the whole static contents to string in this case. And this is one of the selling point of vue 3.

It just happily serialize a big chunk of static template into string and create fragment on runtime with it. So client don't need to create static elements one by one. Besides that, it also mark that static content as "just don't diff it, it won't change", so runtime won't even try to diff it.

https://shorturl.at/aijOQ

Switch to the js panel and you will realize that it already serialize the whole v-node thing into html on build time.

Re: Virtual DOM is pure overhead (2018)

#135

Post by ttfkam »

acdha wrote: post #77
maxfurman wrote: post #10

I like the looks of Svelte, but this argument is a bit strong. The supposed benefit of virtual DOM being: X application-level virtual DOM changes -> differ detects only Y Y final DOM operations is faster than X application-level virtual DOM changes -> no virtual DOM diffing -> X DOM operations this depends a lot of how fast the diffing is and how fast the DOM is but unless DOM operations are instant now (and with CSS…

The browser renders the DOM, so everything pays the cost of updating it. In modern browsers that's really, really, really fast compared to IE6 (the baseline when React was designed), so there are basically two things which make one tool slower than another: 1. Are you updating nodes unnecessarily, especially in ways which force the browser to do more work (see next point)? In general, a tool which does only does the…

3. Does the solution require more thought and library expertise to get the same task done?

Compilers were a huge boon over hand-built machine code and assembly. In specific hot spots, someone can eke out better performance sometimes, but compilers emit pretty good performance all the time with much lower effort from the programmer. Early compilers were just okay. Modern compilers can regularly kick 99% of human skills to the curb with aggressive pipelining, speculation, and vector operations.

React is the assembly language in this analogy.

    let count = 1;
is demonstrably better than

    let [ count, setCount ] = useState(0);
Not having to keep useMemo() in mind all the time is demonstrably better when performance can be maintained without having to worry about it.

Less code = fewer bugs

Less code with equal or better performance is golden.

Re: Virtual DOM is pure overhead (2018)

#136

Post by dangoor »

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 reasonable to question whether all of this belongs together, but all of this evolution _has_ allowed for whole new classes of applications to be delivered securely and quickly to all sorts of devices in the browser.

Re: Virtual DOM is pure overhead (2018)

#137

Post by AtlasBarfed »

com2kid wrote: post #105
pweissbrod wrote: post #91

In more cases than not I've noticed the choice of single page app itself is pure overhead. SPA technology brings some key advantages but also a whole new realm of cost and complexity. It's my experience that SPA popularity has convinced many folks to use it when they really don't have a practical reason to justify it.

Svelte is so insanely lightweight, I think it is a great counter argument to a lot of the SPA hate. And honestly, most of the weight in modern websites comes from analytics and tracking tools. I've made insanely performant SPAs that work well on low budget hardware. My personal phone is 5 years old, if code I write doesn't perform flawlessly on it I'm not going to ship it to customers! Heck my personal dev laptop is…

I wish there was a "works for Pentium III" label that would help indicate that the app's usability hits necessary minimums on a 1Ghz Pentium III computer. IMO that would be a good optimization floor for avoiding the hidden monstrosity of electron apps and that type of stuff.

If your McCrud app can't be responsive on a baseline 1Ghz PIII with 1GB of RAM, then there needs to be some sort of shame pushback. Moore's law is effectively coming to a close, there will need to be more optimization in the future.

Re: Virtual DOM is pure overhead (2018)

#138

Post by PaulHoule »

TurningCanadian wrote: post #113
PaulHoule wrote: post #73

Earlier quoted context omitted.

There are problems that have to do with the systems built on top of React if not React itself. It is not unusual at all to find some "simple" UI update causes the render() method to be called 20 times. You might blame the application developer for this but other than "keep all the state at the top level of the application and pass it down in props", React doesn't provide a systematic answer for handling state in apps…

> 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 your computer. Does Micron pay Facebook a commission for all the RAM this sells? Maybe people who are trying to keep their code obfuscated think it is a big win.

I am glad that the React team has painted themselves into a corner and they can't seem to successfully land new malfeatures like context, hooks, etc. It seems like they are re-arraigning the deck chairs on the Titanic repeatedly to prepare for the threaded rendering changes that they (hopefully) won't be able to deliver so at least the React development experience is not going to degrade quickly.

Re: Virtual DOM is pure overhead (2018)

#139

Post by taftster »

aranchelk wrote: post #92

I take “pure overhead” to mean a cost with literally no benefit. To me that just makes it sound like Svelte is being pushed by idiots, because clearly there’s a substantial benefit (regardless of whether or not VDOM is an optimal strategy). From the end of this article: “Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough…

We live in the era of click-bait titles and these manifest even by, what you would hope, are more reputable establishments. The author obviously agrees with your sentiment (given the quote you cited), but it's too easy and just the norm to be hyperbolic in your blog title, articles or essays.

Re: Virtual DOM is pure overhead (2018)

#140

Post by c-smile »

c-smile wrote: post #123
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…

It depends how really you use virtual DOM. React's "reconciliate whole world" approach can be excessive, yes. But, for example in Sciter, vDOM works in [web] component cases that are similar to Svelte: class Beers extends Element { bottles; render() { return {this.bottles} } set value(v) { this.componentUpdate({bottles:v}) } } When you will do document.$(".bottles").value = 12; it will update only what is needed. Pre…

To make it even closer to Svelte, Sciter has native signal() implementation, so

   let bottles = signal(0);

   function Beers() {
       return  1}>{bottles.value} bottles of beer
   }

   document.body.append();
That can be updated by simply changing signal:

   bottles.value = 42; // Party time!
Note: this does not require any preprocessors or precompilations.
Post reply on HN