Hacker News Reader

Comment by yladiz | Hacker News Reader

Do you think it’s solely because of React?

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

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

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

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

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

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

As I said, this project was about as complex as Figma: a feature rich collaborative editor. This designation has nothing to do with code size.

Go hook up the React dev tools to Reddit and look how much each component renders. You see that components are constantly rendering even though nothing apparent has changed. I get that ideally React would only re-render when something has changed, but clearly it’s easy to create situations where react thinks something has changed even if it hasn’t.

Another good example is the Facebook website itself. It’s just so slow. I get saying Reddit developers suck, but I don’t think you can say the same about FB developers given that FB made React. React is popular because it’s a good developer experience. It’s not the best choice if you want optimal performance.

I have a hard time assuming you are not confusing network delays with rendering speed...

Yes, that seems to be a common theme: you have a hard time believing anything that doesn’t fit with your preconceived notions.

Again, connect React dev tools to Reddit yourself. Given that you’ve been given a concrete example of a slow website, I have a hard time believing you can even differentiate a performant website from a slow one.

As well, people don't understand that React is an idempotent rendering framework. It's easy to reason about because of the same reason why functional languages are easy to reason about, it does not mutate but instead creates new copies.

This is a discussion about perf. Creating new copies is part of what makes it slow.

The point is the same as functional languages, making immutable copies is what makes it easy to reason about, where reactive changes don't. There are ways to make VDOMs fast too, faster than reactive frameworks.

Understanding that part means you know where to use memoization to speed up what needs to speeding up. Which isn't that much, usually.

Well, we all seem to be in agreement that excessive rerenders are the leading cause of poor performance, and reactive frameworks are the solution.

The only performance bottleneck (I can think of) at scale with these frameworks is bundle size. Components are marginally larger in solid, and much larger in svelte. Fortunately, components don't all need to be loaded at once, and react has a lot of weight from the getgo. I cannot imagine a situation where the increased component size of svelte or solid would actually result in a larger app, even before weighing the performance gains from reactivity.

One other thing to note: An old team tried scaling with svelte once, and we ended up with react. This isn't related to performance, just DX. Solid is going much better, the primitives approach makes scale easy to reason with.

> Components are marginally larger in solid, and much larger in svelte.

That doesn't sound right. Components are usually much smaller in Svelte, both source and compiled output; if you have hydration enabled, the JS only contains code needed to hot-patch the DOM, and not rebuild the entire template including all the static parts as react/solid does.

When Svelte still called itself the "disappearing framework", the trade-off was larger overhead in the overall project due to repeated code, but in later versions Svelte ships a runtime with a shared library.

> we all seem to be in agreement that excessive rerenders are the leading cause of poor performance, and reactive frameworks are the solution

When we were hand-wiring components in Backbone, knockout.js etc, rendering was extremely optimized, since you decided on each and every action that would trigger it, and you did not want to overwrite potentially stateful DOM elements unless really needed.

It was way easier to get stuck into infinite loops, get desync issues, or simply completely loose track of chains of events, but unnecessary re-renders were not a major issue because they were much more expensive. React offered a solution to reason about the component tree more clearly, and along with flux and the unidirectional data flow, eliminate issues around stale data and mutations. It was not meant to be faster.

> The trade-off was larger overhead in the overall project due to repeated code, but in later versions Svelte ships a runtime with a shared library.

This is news to me! I switched off svelte in 2021, and onboarded with solid in early 2022. This excites me to check out svelte again

> It was not meant to be faster.

Well, this whole discussion is performance so...

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

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

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

Reply on news.ycombinator.com