4 ms·

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 poke

by 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

by Kuinox 5y ago

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