[sysbin]

Question: Would vanilla js be faster than using react and when just using functions that handle hiding & showing divs by changing the css visibility value? I always assumed optimized react was somehow significantly reducing the browser rendering in the background but I’m unsure now when reading the comments.

[aylmao]

> Would vanilla js be faster than using react and when just using functions that handle hiding & showing divs by changing the css visibility value?

Yes.

> I always assumed optimized react was somehow significantly reducing the browser rendering

Let's say you add a <div>. The least amount of rendering you can do, is the render associated with of that new <div>. If you code this manually, you can guarantee you only add the div, and not modify anything else. This is theoretically the best it can be, and so the best React can do as well, from the rendering standpoint.

From the work standpoint, React does many more things associated with stuff that make it work. From the vdom, to the scheduler— it's all overhead React pulls in so it can function. So in holistically in terms performance, adding that <div> yourself is always going to be faster than doing so through React— the less code to run the faster something is.

What React gives you is a framework to think about your application's architecture and execution. Adding a <div>, easy to do manually, no problem. Rendering a whole application, with thousands of possible states, moving parts, some data-fetching here, some animation there, all the while the user is clicking buttons in the middle of state updates— that's harder. At that point can you be sure you're hand-writing the optimal solution, taking into consideration not only _what_ you're rendering, but _when_ it's updating, _how_ the data is changing, and _where_ these mutations are taking place? That's what React gives you. And maybe it doesn't (always) do what's optimal for you, but it does at least provide order to all this complexity, so you can more easily figure it out.

[runawaybottle]

You have to go back a bit and see why the fuss over rendering performance even exists:

https://johnresig.com/blog/the-dom-is-a-mess/

If the vdom can do the diff and sync all the changes to one DOM update, you only trigger one re-layout. That’s one of the main reasons to have the vdom, to offset shitty DOM performance by using app memory. The browser really sucked/sucks.

I urge everyone to keep track of the history of JS frameworks, and why we even gravitate towards these frameworks.

[rimliu]

DOM operations are costly whether you do them or React does them. What React offers is avoiding unnecessary DOM operations. However if you need to perform two operations, and React still needs to perform two operations, vanilla will be faster by avoiding all the extra work with VirtualDOM rerendering and diffing. Virtual DOM is taken by many as granted and cost-free, which is not true. If your SPA is comples and hats a lot of components, then on each data change all thad virtual rerendering and diffing kicks off and even if at the end no DOM opreations need to be done, i.e. nothing changes visually all this adds up in terms of CPU resources.