9 ms·
On the other hand, React is super slow, a problem which is further exacerbated by the fact that rendering and invalidation happens somewhat indirectly, meaning
by rcme 4y ago
On the other hand, React is super slow, a problem which is further exacerbated by the fact that rendering and invalidation happens somewhat indirectly, meaning it’s really easy to accidentally make something super slow.
For your run of the mill website, this probably doesn’t matter. But for interactive web content, it can absolutely be a competitive advantage to use something faster and more responsive.
- MajimasEyepatch 4y agoI don’t think I’ve ever seen a web app where the performance of React was such a bottleneck that it would in any way justify migrating to another tech stack. You’d have to get so far into a project for that to become an issue that the cost of switching would be huge.
- rcme 4y agoHave you tried the new Reddit website?
- deleted 4y ago[deleted]
- yladiz 4y agoDo you think it’s solely because of React?
- rcme 4y agoIf you read my original post, one of my points was that React’s rendering and data model makes it too easy to render unnecessarily, which causes perf issues.
- yladiz 4y agoI would say “can cause” performance issues, but I wouldn’t say React is one of the primary reasons for poor performance. You can get very far with little optimization in React, so I am skeptical that the way React works fundamentally causes issues.
- ricardobeat 4y agoYMMV. I've been involved in multiple large-scale React projects at this point, and they all eventually suffered from performance issues, related to React's rendering model. And fixing it is always painful. On Reddit, as another comment mentioned, yes, React seems to have been a major factor in how slow it became due to the patterns it encourages, and the massive JS sources. You can only 'get very far' because browsers are crazy fast and you don't notice what's going on underneath. Until it catches up to you.
- bayesian_horse 4y agoThen you would need to show me proof that other frameworks handle similar complexity with less performance degradation or optimize with less pain. My general advice in such cases would be to strive for more isolation. Do use Redux. Don't be afraid to use multiple stores on one page if that allows you to isolate rerenders.
- rcme 4y agoI have experiencing on both complex React projects and complex vanilla JS projects (think the scale and complexity of Figma). Vanilla JS lends itself to being more performant. Anything that happens in Vanilla JS happens for an explicit, developer-defined reason. Things don’t rerender unless explicitly asked to. This can be both good and bad. While Vanilla JS tends to stay way more performant as complexity scales, “stale state” bugs are much more common. It’s a tradeoff.
- bayesian_horse 4y agoI had the exact opposite experience. I mean, first of all, people using "VanillaJS" get the DOM manipulation wrong a lot more often. And then I do hope you don't conflate code size with complexity, because of course, direct DOM manipulation takes one heck of a lot more code (unless you create and maintain your own bespoke framework creating your own headaches). You are basically contradicting the whole reason Facebook, a pretty big and quite smart company, started React in the first place. You also don't seem to understand what "rerendering" means. And that is often a problem in terms of performance. A React component only executes to determine if things have to be changed in the DOM. Not understanding this is creates a lot of pain.
- pxtail 4y ago> Do you think it’s solely because of React? Yes, if the company like reddit, facebook - which has prestige, finances and ability to hire rockstar-10x-A-players React/JS developers is unable to get their shit right and their react fronts works like garbage then it simply means that there is no hope, for some reason it's simply not possible to make performant app with React.
- satvikpendem 4y agoOr it's purposefully bad to incentivize people to use their app which has more tracking. I've had React frontends that were performant and plain JS frontends that were laggy. It's not really a factor of the framework.
- belmont_sup 4y agoThe other way around is to point at great React based apps. Linear’s project management tool is so quick and fast. It takes a whole mindset embedded into a team to make a product fast from the get-go.
- anonymoushn 4y agoAs soon as a web site adds the feature where content is removed when out of the viewport and the browser's find feature no longer works, that web site has reached this point and is deploying workarounds that harm the user experience. Facebook and Twitter have had this feature for most of a decade.
- internetter 4y agoOh lord I thought it was just me. Browsers are really good at displaying long lists, just maybe not loading them all at once ;)
- Yoric 4y agoI 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
- internetter 4y agoEveryone seems to be saying that the performance doesn't matter, but as a general consumer and an employee with ADHD, I absolutely notice every millisecond, and have been known to abandon products over it (or make my own frontend, depending on the viability of alternatives). Like, I can feel the delay typing in a web browser compared to native, and it drives me crazy. If the output doesn't seem like a direct response to my input, I lose focus. Simple as that, and react seems to be a big part of that problem. We have ways to go in our apps, but solid has done wonders already. Currently I'm researching state caching and optimistic updates, both of which should also improve it. Fast enough is a myth. Instant apps are magic.
- TexanFeller 4y agoAlso an ADHD person. He's not exaggerating. I do notice every single 100ms delay in the computer doing what I commanded.
- bayesian_horse 4y agoBullshit. "React is super slow" is just not true in any shape or form. Especially not React itself. And even if React itself or the way it does things is "too slow" (which is the only metric that counts) then there are escape hatches or ways to deal with that.
- sunshinerag 4y agowhat would one do with React itself.?