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

41–50 of 337 posts

Re: Virtual DOM is pure overhead (2018)

#41

Post by afavour »

msoad wrote: post #37
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.

You can't parallelize DOM updates. All has to happen in the main loop. This is not gonna change for the web as it is today.

I don't think that's what OP is saying. They're saying that (e.g.) calculations are made on each appendChild() call when it would be more efficient (when you know you're going to be inserting a ton) to suspend all calculation, insert 1000 nodes, then resume calculations. Something akin to setNeedsLayout() on iOS:

https://developer.apple.com/documentation/uikit/uiview/16226...

Re: Virtual DOM is pure overhead (2018)

#42

Post by fassssst »

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…

I mean in the native Windows app world you just have your “ViewModel” raise an event with the name of the property that changed, and the UI layer just goes and assigns the new value to the appropriate element(s). Much simpler and easier to debug than vdom approaches.

Re: Virtual DOM is pure overhead (2018)

#43

Post by overgard »

msoad wrote: post #37
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.

You can't parallelize DOM updates. All has to happen in the main loop. This is not gonna change for the web as it is today.

My point is that if you change the DOM api itself thats the win. Right now its just individual property updates, so the browser can't know when to delay a computation. So definitely not part of the web today, but it seems worth considering.

Re: Virtual DOM is pure overhead (2018)

#44

Post by dmix »

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 building large blocks of HTML. But if the bulk can be rendered server-side that overhead isn't an issue. So you can address this by simply reducing the data binding to the bare minimum of HTML that actually need to be interactive.

That way you can use the same templating and component systems app-wide but the default is still static-first.

That said - the Cons section notes: "The architecture is not suitable for highly interactive pages like social media apps which would probably require thousands of islands." But at that scale there's often far more performance concerns than vDOM vs compiler vs [some better optimized templating system], where the benefits aren't as straightforward (as linked below https://twitter.com/dan_abramov/status/1135423065570127872).

Re: Virtual DOM is pure overhead (2018)

#46

Post by overgard »

afavour wrote: post #41
msoad wrote: post #37

Earlier quoted context omitted.

You can't parallelize DOM updates. All has to happen in the main loop. This is not gonna change for the web as it is today.

I don't think that's what OP is saying. They're saying that (e.g.) calculations are made on each appendChild() call when it would be more efficient (when you know you're going to be inserting a ton) to suspend all calculation, insert 1000 nodes, then resume calculations. Something akin to setNeedsLayout() on iOS: https://developer.apple.com/documentation/uikit/uiview/16226...

Yes, that's exactly my point, thanks for expressing it better than I could

Re: Virtual DOM is pure overhead (2018)

#47

Post by thomasikzelf »

svachalek wrote: post #35
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…

I'm sure there's a different concept in there somewhere, but what you described sounds exactly like vdom.

Let's call it vdata. Data diffing instead of DOM diffing.

Re: Virtual DOM is pure overhead (2018)

#48

Post by napkin »

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.

Re: Virtual DOM is pure overhead (2018)

#49

Post by c-smile »

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(vDOM):

   Element.patch(new text);
as the later is more humanistic I would say.

Re: Virtual DOM is pure overhead (2018)

#50

Post by synalx »

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…

This is also a core design principle of Angular - the compiler extracts the static template structure and generates code to update dynamic bindings within it.
Post reply on HN