Virtual DOM is pure overhead (2018) • Hacker News Board

Re: Virtual DOM is pure overhead (2018)

#121

Post by Closi » Wed, Feb 01, 2023, 6:02 PM UTC

jcelerier wrote: post #80

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…

> 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. we don't live in the same universe. even with powerful computers, browsing any friggin modern website is an exercice in pain and frustration, everything, literally every interaction is slow when you compare to the average desktop app

Agree, and I think this is the point of the article too.

If we are going to say things like "React is fast" then it needs a further clarification - fast compared to what?

Are we comparing it to C, jQuery, Angular, Pure Javascript, or a Commedore 64? Because it doesn't make sense to say it is fast if there isn't something to compare it against.

(In reality, I suspect it is only really "fast" if you compare it with something slow).

Re: Virtual DOM is pure overhead (2018)

#122

Post by mistersys » Wed, Feb 01, 2023, 6:02 PM UTC

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…

No need to be pedantic. He's obviously saying that there are better strategies then vDOM with lower overhead.

This is proven by Solid.js which is faster then every VDOM framework, has an API that is functionally the same as react, and doesn't use VDOM.

Re: Virtual DOM is pure overhead (2018)

#123

Post by c-smile » Wed, Feb 01, 2023, 6:02 PM UTC

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…

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. Pretty much Svelte style but with the convenience of vDOM.

Re: Virtual DOM is pure overhead (2018)

#124

Post by renlo » Wed, Feb 01, 2023, 6:03 PM UTC

ruduhudi wrote: post #56

Can we please talk about how much reactive programming sucks for UIs? I miss all the people who switched from angular to react for a reason in these discussions... I'd bet none of those are going to move to svelte.

I switched from Angular to React 8 years ago, and I've no interest in Svelte. If I recall correctly the primary problem with Angular was $watch, race conditions, etc, meanwhile with React your state is your state, purely functional and idempotent, which is a feature of "reactive programming". Reactive programming is fantastic.

Re: Virtual DOM is pure overhead (2018)

#125

Post by ko27 » Wed, Feb 01, 2023, 6:04 PM UTC

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.

It's actually the opposite. MPAs are pure overhead. In theory SPAs are faster because they only require a minimum of 1 user blocking network request, while MPAs need at least 1 for each page. Everything else is up to the implementation. So if you are doing heavy performance optimizations, SPAs will always end up faster. However that's not the full picture, and in practice there is a lot of nuance, but SPAs definitely have a higher performance ceiling.

Re: Virtual DOM is pure overhead (2018)

#126

Post by pweissbrod » Wed, Feb 01, 2023, 6:07 PM UTC

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…

By choosing an SPA. You must choose a dedicated static site hosting which is separate from your web application. You may already have this but you may not. In most cases you must choose a framework for routing. Also a framework for state management. You also dedicate to duplicating validation and security trimming logic both on the client side and the server side. More often than not you will find yourself including hundreds of NPM packages as dependencies which you must continually update and maintain. Also the requirement for unit testing on the front end is common. Which brings in the need for things like jest and enzyme. This complexity inevitably trickles into your build and deploy processes. Perhaps in larger teams this is a burden you can absorb. In smaller teams however you start to see division of responsibilities. One person only knows front end but not back end and vice versa. Common knowledge of the application as a whole can become fragmented. Perhaps the day comes where you want to take a partial of a user interface posted in a peripheral application and place it inside your web page. Because you have a virtual DOM this is now a security risk. You must build a component which duplicates the user interface which already exists. If the user interface needs to be shared among many applications you must build a commons code base to host your components. You start shouldering the burden of maintaining component libraries instead of just HTML and CSS. Again this is all very general and hypothetical but it feels worth pointing out some of the common implications that simply choosing an SPA can have in the longer run.

Plus this is not an all or nothing sort of choice. For decades we have used Ajax to perform partial updates on a web page. Consider alternatives like HTMX as a comparison.

Re: Virtual DOM is pure overhead (2018)

#127

Post by dang » Wed, Feb 01, 2023, 6:07 PM UTC

Virtual DOM is pure overhead (2018) - https://news.ycombinator.com/item?id=19950253 - May 2019 (332 comments)

Re: Virtual DOM is pure overhead (2018)

#128

Post by divan » Wed, Feb 01, 2023, 6:08 PM UTC

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?

Re: Virtual DOM is pure overhead (2018)

#129

Post by pweissbrod » Wed, Feb 01, 2023, 6:08 PM UTC

ko27 wrote: post #125

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.

It's actually the opposite. MPAs are pure overhead. In theory SPAs are faster because they only require a minimum of 1 user blocking network request, while MPAs need at least 1 for each page. Everything else is up to the implementation. So if you are doing heavy performance optimizations, SPAs will always end up faster. However that's not the full picture, and in practice there is a lot of nuance, but SPAs definitely…

Not for large DOMs. And for websites which Don't require support for low internet bandwidth this is optimizing for the wrong problem

Re: Virtual DOM is pure overhead (2018)

#130

Post by svieira » Wed, Feb 01, 2023, 6:10 PM UTC

dmix wrote: post #44

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…

> The key observation about HTML templates is that usually large portions of them don't change with new data. Isn't this a core idea underneath the https://fresh.deno.dev/ "islands" and I believe the https://astro.build/ framework when they confronted issues around hydration/SSR? https://www.patterns.dev/posts/islands-architecture/ Clearly there's some overhead via the vDOM and simply using React-like templates when…

Also Marko, which was on here yesterday: https://markojs.com/docs/why-is-marko-fast/#compile-time-opt...

> Marko will recognize that the template fragment produces the same output every time and it will thus create the virtual DOM node once ... Rendering a static sub-tree has virtually zero cost. In addition, Marko will skip diffing/patching static sub-trees.

> Marko will also optimize static attributes on dynamic elements. [Static] attributes [are] only created once and [are] used for every render. In addition, no diffing/patching will happen for static attributes.