[simjnd]

It is pretty established at this point that React has (relative) terrible performance. React isn't successful because it's a superior technology, it's successful despite being an inferior technology. It's just really difficult to beat an extremely established technology and React has a huge ecosystem, so many companies depend on it that the job market for it is huge, etc.

As to why it is slow, my knowledge is super up-to-date (haven't kept up that well with recent updates), but in general the idea is:

- The React runtime itself is 40 kB so before doing anything (before rendering in CSR or before hydrating in SSR) you need to download the runtime first.

- Most frameworks have moved on to use signals to manage state updates. When state change, observers of that state will be notified and the least amount of code will be run before updating the DOM surgically. React instead re-executes the code of entire component trees, compares the result with the current DOM and then applies changes. This is a lot more work and a lot slower. Over time techniques have been developed in React to mitigate this (Memoization, React Compiler, etc.), but it still does a lot more work than it needs to, and these techniques are often not needed in other frameworks because they do a lot less work by default.

The js-framework-benchmark [1] publishes benchmarks testing hundreds of frameworks for every Chrome release if you're interested in that.

[1]: https://krausest.github.io/js-framework-benchmark/2025/table...

[maelito]

> It is pretty established at this point that React has (relative) terrible performance. > it is slow

You're not answering my question, just adding some more feelings.

> The React runtime itself is 40 kB

React is < 10 kb compressed https://bundlephobia.com/package/react@19.2.0 (add react-dom to it). That's not really significative according to the author's figures, the header speaks about up "to 176.3 kB compressed".

> Most frameworks have moved on to use signals to manage state updates. When state change

This is not kilobytes or initial render times, but performance in rendering in a highly interactive application. They would not impact rendering a blog post, but rendering a complex app's UI. The original blog post does not measure this, it's out of scope.

[simjnd]

> You're not answering my question, just adding some more feelings.

Well you seemed surprised by this fact, even though it's a given for most people working in front-end frameworks.

> React is < 10 kb compressed https://bundlephobia.com/package/react@19.2.0 (add react-dom to it).

I don't know how bundlephobia calculates package size, and let me know if you're able to reproduce them in a real app. The simplest Vite + React app with only a single "Hello, World" div and no dependencies (other than react and react-dom), no hooks used, ships 60+ kB of JS to the browser (when built for production, minified and gzipped).

Now the blog post is not just using React but Next.js which will ship even more JS because it will include a router and other things that are not a part of React itself (which is just the component framework). There are leaner and more performant React Meta-Frameworks than Next.js (Remix, TanStack Start).

> This is not kilobytes or initial render times, but performance in rendering in a highly interactive application

True, but it's another area where React is a (relative) catastrophe.

The large bundle size on the other hand will definitely impact initial render times (in client-side rendering) and time-to-interactive (in SSR), because it's so much more JS that has to be parsed and executed for the runtime before even executing your app's code.

EDIT: It also does not have to be a highly interactive application at all for this to apply. If you only change a single value, that is read in a component deep within a component tree you will definitely feel the difference, because that entire component tree is going to execute again (even though the resulting diff will show that only that deeply nested div needs to be updated, React has no way of knowing that beforehand, whereas signal-based framework do)

And finally I want to say I'm not a React hater. It's totally possible to get fast enough performance out of React. There are just more footguns to be aware of.

[acemarke]

React's bundling system and published packages has gotten noticeably more complicated over time.

First, there's the separation between the generic cross-platform `react` package, and the platform-specific reconcilers like `react-dom` and `react-native. All the actual "React" logic is built into the reconciler packages (ie, each contains a complete copy of the actual `react-reconciler` package + all the platform-specific handling). So, bundle size has to measure both `react` and `react-dom` together.

Then, the contents of `react-dom` have changed over time. In React 18 they shifted the main entry point to be `react-dom/client`, which then ends up importing the right dev/prod artifacts (with `react-dom` still supported but deprecated):

- https://app.unpkg.com/react-dom@18.3.1/files/cjs

Then, in React 19, they restructured it further so that `react-dom` really only has a few utils, and all the logic is truly in the `react-dom/client` entry point:

- https://app.unpkg.com/react-dom@19.2.0/files/cjs/react-dom.d...

- https://app.unpkg.com/react-dom@19.2.0/files/cjs/react-dom-c...

So yes, the full prod bundle size is something like 60K min+gz, but it takes some work to see that. I don't think Bundlephobia handles it right at all - it's just automatically reading the main entry points for each package (and thus doesn't import `react-dom/client`. You can specify that with BundleJS though:

- https://bundlejs.com/?q=react%2Creact-dom%2Fclient&treeshake...

> Bundle size is 193 kB -> 60.2 kB (gzip)

[maelito]

Thanks for the detailed explanations !

[simjnd]

You're welcome