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

Re: Virtual DOM is pure overhead (2018)

#171

Post by bsaul » Wed, Feb 01, 2023, 7:27 PM UTC

mistersys wrote: post #114

paales2 wrote: post #5

Inferno.js uses VDOM https://github.com/infernojs/inferno and is faster than Svelte according to these benchmarks https://krausest.github.io/js-framework-benchmark/2023/table... . Sooo, VDOM can improve performance?

Solid.js is even faster than inferno, and it doesn't really use a VDOM strategy, uses a strategy much more like svelte. IMO svelte is just poorly implemented from a benchmark perspective. In reality, most of these benchmarks are not meaningful when talking about real app performance. What's meaningful is how you do global state updates in your app. If you use a react app with react-hook based context providers that u…

damn, just when i thought the "1 new js framework a day" race had calmed down, i'm reading your comment and realize it hasn't one bit :)))

Re: Virtual DOM is pure overhead (2018)

#172

Post by hbrn » Wed, Feb 01, 2023, 7:29 PM UTC

afavour wrote: post #36

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…

> They are all fast I would say they all can be fast. But try browsing the web on a low end Android device and tell me all sites are fast. To my mind the differentiator is how easy a framework makes it to shoot yourself in the foot. And React makes it very easy to re-render a huge swathe of your app when you've only changed one tiny element. React also needs to hydrate every element even when it isn't ever going to c…

> differentiator is how easy a framework makes it to shoot yourself in the foot

I agree. In fact this goes beyond frontend frameworks. One should apply the same approach to all methodologies and practices: OKRs, TDD, Agile, etc.

When framework/methodology is being sold to you, people talk about all the wonderful properties it has. But what you should really be care about is how easy it is to misuse and what happens when it does get misused. Because, trust me, it will get misused.

One of the most important things about particular technology is whether it lands you in a Pit of Success: https://blog.codinghorror.com/falling-into-the-pit-of-succes...

Re: Virtual DOM is pure overhead (2018)

#173

Post by Rapzid » Wed, Feb 01, 2023, 7:29 PM UTC

mistersys wrote: post #122

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.

I believe Solid has also kinda shown that.. Well, I like its low-touch approach compared to svelte's need for heavy compiling and a new language essentially.

With Solid can use JSX and it doesn't even need, last I checked, anything beyond standard JSX transformation to get pretty good results. It's the better direction IMHO even if the Solid APIs feel like they need another iteration or so.

Re: Virtual DOM is pure overhead (2018)

#174

Post by yuzuquat » Wed, Feb 01, 2023, 7:33 PM UTC

runarberg wrote: post #76

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(…

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.

I'd be interesting in learning the answer here as well. I've read that documentFragment are faster, but some microbenchmarking on chrome/mac makes me think either the improvements are negligible. Rerunning benchmarks on stackoverflow (https://stackoverflow.com/questions/14203196/does-using-a-do...) (both individually and swapping the order of fragment vs non-fragment tests) nets me ~60ms when rendering 100000 ul in each case.

My naive take on this is that browsers have overall gotten a lot more consistent with the layout-paint-composite loop, and it's not worthwhile to swap out all your appendChild calls with fragments. On the other hand, making sure your all your layout reads (.clientWidth) are batched before the layout writes (appendChild) is much more important (fastdom)

edit: something like documentFragment/append(...children) would help guarantee the layout trashing addressed by fastdom

Re: Virtual DOM is pure overhead (2018)

#175

Post by c-smile » Wed, Feb 01, 2023, 7:36 PM UTC

PaulDavisThe1st wrote: post #166

Reading this as a native developer is a bit like reading about alchemy or astrology - two fields with their own vast suite of terminology and internal logic that doesn't fully correspond to anything real ... ... only to find out that this stuff is actually real and is how a big chunk of the visible web actually works.

> native developer

You probably haven't done any native UI as native UI uses exactly the same idiom.

    CWnd* parent = ...
    parent->appendChild( new EditBox() );

native UI also uses DOM concept, it is just that instead of child elements it uses term child windows or [Gtk]widgets or [ns]View s.

Re: Virtual DOM is pure overhead (2018)

#176

Post by ko27 » Wed, Feb 01, 2023, 7:41 PM UTC

pweissbrod wrote: post #129

ko27 wrote: post #125

Earlier quoted context omitted.

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

Network latency is your no.1 bottleneck for every modern device, everything else is a distant second. Also you can optimize everything, but you can't make MPAs navigate without a network roundtrip.

Re: Virtual DOM is pure overhead (2018)

#177

Post by mrtranscendence » Wed, Feb 01, 2023, 7:45 PM UTC

c-smile wrote: post #146

mhink wrote: post #132

Earlier quoted context omitted.

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.

Not on my browser (Safari 16.1). Here case #3 is the fastest, over 7% faster than case #1.

Re: Virtual DOM is pure overhead (2018)

#178

Post by ttfkam » Wed, Feb 01, 2023, 7:49 PM UTC

c-smile wrote: post #140

c-smile wrote: post #123

Earlier quoted context omitted.

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.

Let's compare lines of code, because more lines invariably leads to more bugs.

Contents of Beers.svelte:

    
      export let bottles = 99;
    
    
    {#if bottles > 0}
       --bottles}>
        {bottles} bottles of beer on the wall
      
    {:else}
      
        No more bottles of beer on the wall
      
    {/if}

Then to use it:

    
      import Beers from './Beers.svelte';

No knowledge of Reactor's existence needed let alone the library's "signal" function. No functions needed at all. No bespoke syntax for the "bottles" CSS class. No vDOM API call. No extra "values" accessing property. It's >90% plain old HTML, CSS, and JS with literally the bare minimum of syntax to handle data binding.

Yes, it requires a compiler, but I would honestly astounded if you even noticed the compiler build time in dev mode. AND the deployed code is smaller. AND it's simpler for the dev to understand and maintain. AND it's likely faster at runtime.

The argument that Svelte adds mental overhead is manifest nonsense. If you like the vDOM, have at it. Follow your bliss. Some folks like hitting and kicking trees. Some folks prefer their coffee too hot to drink.

I for one want a web framework that makes web development as simple, straightforward, and powerful as possible. HTML, CSS, and the smallest amount of JS and HTML annotation imaginable.

Re: Virtual DOM is pure overhead (2018)

#179

Post by yuzuquat » Wed, Feb 01, 2023, 7:53 PM UTC

c-smile wrote: post #49

overgard wrote: post #32

Sadly, it seems like nobody is considering the best optimization: make DOM operations fast. I think if you could batch DOM operations together you could avoid a lot of wasted relayout and duplicate calculations.

I was thinking of how to improve DOM updates. One of ideas is to add Element.update() method: Element.update(function(updateCtx) { updateCtx.setInnerText(this, "new text"); updateCtx.setAttribute(this, "title", "new title"); ... }); This has two benefits: 1) transactional update, 2) for contenteditable scenarios it can group DOM mutations in atomic undo-able action. But I've discarded that in lieu of Element.patch(vD…

My feeling is that the browser already does this in that it considers all DOM apis within a single 16ms (requestAnimationFrame?) as a single transaction.

The trouble for browsers, is if certain DOM apis have a dependency on the layout of another element. My naive and unvalidated understanding:

    // Good: These DOM calls in a single frame will trigger layout-paint-composite (1 loop)
    - e.style.backgroundColor = "red";
    - e.style.width = "20px";
    - e.style.transform = "translateX(10px);

    // Bad: These DOM calls in a single frame will trigger layout-?-layout-paint-composite (2 loops)
    - ...
    - e.style.height = otherElement.offsetWidth + 200 + "px"
    - ...

The reason being that without knowing the width of "otherElement", there's no way for the js runtime to execute the "e.style.height" line and execution needs to be paused while layout occurs.

If you're looking for a transactional syntax (similar to what you've proposed) that also addresses this though, fastdom looks like a good option:

    fastdom.mutate(() => { element.style.width = "20px" });

I'm not a browser expert though so if I"m misunderstanding something, would love to know.

Re: Virtual DOM is pure overhead (2018)

#180

Post by scotty79 » Wed, Feb 01, 2023, 7:53 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…

innerHTML can set event handlers so you don't have to assign them separately. And if you re-create dom fragment with innerHTML you can reattach children that didn't change and their handlers are preserved.