Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I haven't used React in a long time, but when I did, one of the main reasons for using it was that it was much faster than most handwritten non-trivial DOM code because it managed to avoid the `write CSS -> read layout` anti-pattern.

What makes React so slow these days?



It's a combination of many things, but imo one of the worst is all the footguns regarding state and the rerenders they cause

https://emnudge.dev/blog/react-hostage

It's so easy, that we monkey patch react to debug it https://github.com/welldone-software/why-did-you-render

Plus the vdom... Isn't great, the bundle size puts react at an inherit disadvantage, and the community has a knack for over reliance on bloated packages


Just people who don't understand how to write performant React, honestly.

There are ways of writing React that result in vast numbers of re-renders... it's not a best practice, but it's relatively easy to make happen, especially if you ignore the official recommendations and pull Stackoverflow answers from 2015.


Sure, to some degree, but you have to wonder why it's so easy for developers to footgun themselves. It's the fault of the language, imo, not bad developers.


I've never seen a language or framework that is both easy to be quickly productive in, and free of footguns.

React is easy to be quickly productive in... thus, it has footguns.


React is easy to use without understanding the component lifecycle. The penalty is poor performamce rather than a non-functional app.

You saw the same thing in the before times with Adobe Flex. So much code from people who had no understanding of the lifecycle - apps that worked but were appallingly slow and buggy.


What would prevent that?


I believe the term is "fine grained reactivity". Basically, components do not rerender when data updates, only the specific part of the DOM dependent on that data.

This alleviates all the footguns that come with rerenders (including the infamous infinite loop) and often results in cleaner code.

I'm partial to solid[0] (there are lots of comparison articles, but I think [1] and [2] show it the best). I believe svelte is similar and vue is experimenting with this as well

[0]: https://www.solidjs.com/

[1]: https://news.ycombinator.com/item?id=30508524

[2]: https://news.ycombinator.com/item?id=35061672


That isn’t always true. Reactivity can make updates faster, but adds more overhead to creating DOM nodes because you need to set up the subscriptions that are used to eventually update them.

To steal a phrase originally about VDOM: “reactivity is pure overhead”. Nothing comes for free!


Maybe in theory, but solid still outperforms react in creations by a considerable amount, and I think most applications will find they are doing a lot more rerenders than insertions anyway


> it was much faster than most handwritten non-trivial DOM code

That would be incredibly rare. Despite the myth propagated, React is unlikely to be faster unless you were doing a ton of interleaved layout-triggering reads and writes. Even naive direct dom-diffing approaches like hyperapp/choo/morphdom can be faster.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: