3 ms·

Can anyone explain the point of the virtual DOM and why it’s not a source of huge performance issues? What I mean as soon as you retain a reference to a DOM ele

Can anyone explain the point of the virtual DOM and why it’s not a source of huge performance issues? What I mean as soon as you retain a reference to a DOM element, it’s lifetime becomes managed by the JavaScript gc - let’s say you build a paginated gallery app in pure HTML and an spa - in the first case, the browser knows that as soon as you navigate away from the page, all those image thumbnails are free real estate, at the latter case it first needs to wait for the spa to release references to the underlying html objects, then the gc needs to run, at which point it can get rid of it.

Kuinox 5y ago
https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead It is a huge performance issue. I tried to do a pokedex in react, you have to use a virtual list, because react/virtual dom is too slow, doing any operation on a plain list with 1k element, like filtering lead to multiples seconds freeze. This also lead to a lot of issues, like not being able to ctrl+f text being out of screen in a virtual list.
- mlajtos 5y ago
  I also did sort-of Pokedex a long time ago [0], but haven't seen any performance issues. No virtualization whatsoever. Code [1] is rather simple. [0]: https://mlajtos.github.io/lb-pokedex/build/ https://mlajtos.github.io/lb-pokedex/build/ [1]: https://github.com/mlajtos/lb-pokedex https://github.com/mlajtos/lb-pokedex
  - Kuinox 5y ago
    I ran a profiling tool. I searched "zz" then deleted these. Deleting it caused a 120ms UI freeze (and I notice it :p): Profiling report: https://share.firefox.dev/3C3OhIq https://share.firefox.dev/3C3OhIq Given I had slightly more entries (a hundred more) and that I had way more node per entry, it led me with way worse performance. Instead of a plain list I have a little summary card per pokemon (which is why I have more node per entry). The naive implementation in Vue run flawlessly(sadly no preview): https://github.com/Kuinox/kuinox_pokedex/ https://github.com/Kuinox/kuinox_pokedex/ Note that the react implementation do weird thing because I tried to get around the issue without success.
    - mlajtos 5y ago
      You can also preserve DOM and just hide non-matching elements, like here: https://codesandbox.io/s/hidden-dawn-odm1m1?file=/src/App.tsx https://codesandbox.io/s/hidden-dawn-odm1m1?file=/src/App.ts...
- torginus 5y ago
  Great article. The fact that Angular, the framework built by the company who also builds the world's most popular browser, does not have a virtual DOM, is very telling.
  - Kuinox 5y ago
    I wouldn't acclaim angular for the performance either. Building apps on it show consistent subpar performance.
    - ramoz 5y ago
      generally speaking, Angular handles dom manipulation better than React and Vue. Angular has managed to simplify its enterprise/production applicability and performance is a first-order feature that's hard to f up. React -- you can f performance up before you're done writing your first component.
  - bstar77 5y ago
    It's actually a terrible article that has no relevance in 2022, and it is even misleading for 2018 standards.
- bstar77 5y ago
  I don't understand your issues here. I built a community app for a hockey league that manages around 120,000 players in the DB. I do tons of loading, sorting and various algorithms on the data. I've never once had React be my bottleneck. Rendering a page server-side and delivering it to users is about as inefficient a process as you can get unless you have massive resources dedicated to an optimization almost no one needs anymore. The virtual DOM is extremely efficient, it just needs more memory and CPU cycles on the client which are resources readily available. Browsers are very good at managing this in 2022. Btw, your code in that article is completely irrelevant... I would not be showing people that article in 2022.
  - Kuinox 5y ago
    I bet you don't display the 120k players at once on the front, you use some sort of virtualised component (like ag-grid) thats put in the DOM only what is displayed on screen, and keep the whole set in memory. It cause an issue: now the search in document browser feature will not work properly. This is acceptable the usecase you are describing(due to the huge dataset), but a lot of interfaces use such virtual list, and it's an PITA for the user. Take Azure DevOps for example: In a lot of place, you can't ctrl+f a project outside the screen, even if it exist, you have to scroll to it. > Rendering a page server-side [...] Nobody talked about server side rendering there. > The virtual DOM is extremely efficient Did you read the article I linked ? The virtual DOM is not "extremely efficient" it's only good at removing uneeded DOM modifications. Not doing these uneeded modifications in the first place is faster.
  - mst 5y ago
    I have hit a point where I've moved my browser from running locally on my laptop to running on a hetzner dedicated server over VNC because it performs ridiculously better so "readily available" is apparently an unfortunately variable claim. I would note however that my laptop is not entirely recent and I'm using firefox and my big pain point has been React Native Web apps like web twitter. So you're likely still mostly right, and the question inevitably becomes "how much mostly is enough for any given application".
    - 5y ago
deleted 5y ago
[deleted]
schwartzworld 5y ago
The reason for the virtual DOM: in react, the entire world is a function that gets rerun on every render. The whole point is to be able to define some state and then render the whole world in accordance with that new state. When react was conceived, Dom updates were very slow and could bottleneck the application. Knowing that your entire UI is running inside a function that gets re-executed with every render, gives a tremendous amount of safety and predictability to your application and makes testing a breeze. But you can't actually rerender the whole world every time because performance, so instead React relies on a JavaScript object to hold a representation of the UI, and then surgically updates only the pieces that need updating. This was React's big thing. The reason people want to move away from virtual dom is because browsers have gotten faster and now the Dom updates aren't the biggest source of overhead.

Kuinox 5y ago

https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead It is a huge performance issue. I tried to do a pokedex in react, you have to use a virtual list, because react/virtual dom is too slow, doing any operation on a plain list with 1k element, like filtering lead to multiples seconds freeze. This also lead to a lot of issues, like not being able to ctrl+f text being out of screen in a virtual list.

mlajtos 5y ago
I also did sort-of Pokedex a long time ago [0], but haven't seen any performance issues. No virtualization whatsoever. Code [1] is rather simple. [0]: https://mlajtos.github.io/lb-pokedex/build/ https://mlajtos.github.io/lb-pokedex/build/ [1]: https://github.com/mlajtos/lb-pokedex https://github.com/mlajtos/lb-pokedex
- Kuinox 5y ago
  I ran a profiling tool. I searched "zz" then deleted these. Deleting it caused a 120ms UI freeze (and I notice it :p): Profiling report: https://share.firefox.dev/3C3OhIq https://share.firefox.dev/3C3OhIq Given I had slightly more entries (a hundred more) and that I had way more node per entry, it led me with way worse performance. Instead of a plain list I have a little summary card per pokemon (which is why I have more node per entry). The naive implementation in Vue run flawlessly(sadly no preview): https://github.com/Kuinox/kuinox_pokedex/ https://github.com/Kuinox/kuinox_pokedex/ Note that the react implementation do weird thing because I tried to get around the issue without success.
  - mlajtos 5y ago
    You can also preserve DOM and just hide non-matching elements, like here: https://codesandbox.io/s/hidden-dawn-odm1m1?file=/src/App.tsx https://codesandbox.io/s/hidden-dawn-odm1m1?file=/src/App.ts...
torginus 5y ago
Great article. The fact that Angular, the framework built by the company who also builds the world's most popular browser, does not have a virtual DOM, is very telling.
- Kuinox 5y ago
  I wouldn't acclaim angular for the performance either. Building apps on it show consistent subpar performance.
  - ramoz 5y ago
    generally speaking, Angular handles dom manipulation better than React and Vue. Angular has managed to simplify its enterprise/production applicability and performance is a first-order feature that's hard to f up. React -- you can f performance up before you're done writing your first component.
- bstar77 5y ago
  It's actually a terrible article that has no relevance in 2022, and it is even misleading for 2018 standards.
bstar77 5y ago
I don't understand your issues here. I built a community app for a hockey league that manages around 120,000 players in the DB. I do tons of loading, sorting and various algorithms on the data. I've never once had React be my bottleneck. Rendering a page server-side and delivering it to users is about as inefficient a process as you can get unless you have massive resources dedicated to an optimization almost no one needs anymore. The virtual DOM is extremely efficient, it just needs more memory and CPU cycles on the client which are resources readily available. Browsers are very good at managing this in 2022. Btw, your code in that article is completely irrelevant... I would not be showing people that article in 2022.
- Kuinox 5y ago
  I bet you don't display the 120k players at once on the front, you use some sort of virtualised component (like ag-grid) thats put in the DOM only what is displayed on screen, and keep the whole set in memory. It cause an issue: now the search in document browser feature will not work properly. This is acceptable the usecase you are describing(due to the huge dataset), but a lot of interfaces use such virtual list, and it's an PITA for the user. Take Azure DevOps for example: In a lot of place, you can't ctrl+f a project outside the screen, even if it exist, you have to scroll to it. > Rendering a page server-side [...] Nobody talked about server side rendering there. > The virtual DOM is extremely efficient Did you read the article I linked ? The virtual DOM is not "extremely efficient" it's only good at removing uneeded DOM modifications. Not doing these uneeded modifications in the first place is faster.
- mst 5y ago
  I have hit a point where I've moved my browser from running locally on my laptop to running on a hetzner dedicated server over VNC because it performs ridiculously better so "readily available" is apparently an unfortunately variable claim. I would note however that my laptop is not entirely recent and I'm using firefox and my big pain point has been React Native Web apps like web twitter. So you're likely still mostly right, and the question inevitably becomes "how much mostly is enough for any given application".
  - 5y ago

deleted 5y ago

[deleted]

schwartzworld 5y ago

The reason for the virtual DOM: in react, the entire world is a function that gets rerun on every render. The whole point is to be able to define some state and then render the whole world in accordance with that new state. When react was conceived, Dom updates were very slow and could bottleneck the application. Knowing that your entire UI is running inside a function that gets re-executed with every render, gives a tremendous amount of safety and predictability to your application and makes testing a breeze. But you can't actually rerender the whole world every time because performance, so instead React relies on a JavaScript object to hold a representation of the UI, and then surgically updates only the pieces that need updating. This was React's big thing. The reason people want to move away from virtual dom is because browsers have gotten faster and now the Dom updates aren't the biggest source of overhead.