3 ms·
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
by Yoric 4y ago
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?
- justrealist 4y agoJust 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.
- internetter 4y agoSure, 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.
- Yoric 4y agoWhat would prevent that?
- internetter 4y agoI 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/ https://www.solidjs.com/ [1]: https://news.ycombinator.com/item?id=30508524 https://news.ycombinator.com/item?id=30508524 [2]: https://news.ycombinator.com/item?id=35061672 https://news.ycombinator.com/item?id=35061672
- deleted 4y ago[deleted]
- jakelazaroff 4y agoThat 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!
- internetter 4y agoMaybe 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
- justrealist 4y agoI'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.
- Marazan 4y agoReact 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.
- internetter 4y agoIt'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 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 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
- ricardobeat 4y ago> 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.