Hacker News Reader

Comment by torginus | Hacker News Reader

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.

View on HN

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.

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.

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/

[1]: https://github.com/mlajtos/lb-pokedex

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

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/

Note that the react implementation do weird thing because I tried to get around the issue without success.

You can also preserve DOM and just hide non-matching elements, like here:

https://codesandbox.io/s/hidden-dawn-odm1m1?file=/src/App.ts...

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.

I wouldn't acclaim angular for the performance either.

Building apps on it show consistent subpar performance.

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.

It's actually a terrible article that has no relevance in 2022, and it is even misleading for 2018 standards.

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.

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.

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".

what are you using for VNC with hetzner? interested in trying this out

https://tigervnc.org

Does some impressive compression tricks that results in it being remarkably snappy.

You may prefer to run Xvnc directly rather than use the wrapper script, depends how you want to set everything up.

I will be honest here that my setup is not properly automated yet because it's inside a jail on a FreeBSD install and the underlying box gets good enough uptime that my current half-assed approach hasn't yet annoyed me into finishing it.

There weren't any interesting gotchas though.

Reply on news.ycombinator.com