React is not the code that gets bundled

A library that reaches the same end result as React, in three kilobytes rather than thirty and runs faster in some situations, is still not an alternative to React.

Start with the numbers because they’re the part that sounds decisive and three kilobytes is better than thirty and that’s not in dispute. If your main bundle is three thousand kilobytes then swapping one for the other changes nothing anybody will notice and you’ve spent a rewrite on a rounding error. Every framework in current use is fast enough to hold sixty frames per second when it’s used properly and hardly any of them add more than a couple of percent to page weight.

Which of those matters depends entirely on who you’re serving and that’s a real decision rather than a general truth and a business tool with five hundred users can afford weight that a consumer product with two hundred million cannot. Choosing your technology against your actual audience is the sensible version of this argument and it’s not the version that gets made.

What most developers should be weighing instead is the ecosystem, the tooling, the documentation, the quality of the code itself and how testable the thing is. That’s where React is really strong. There’s an enormous supply of good libraries, several excellent tools, documentation that’s unusually well written and a core that’s accessible enough to read when you need to know what it’s doing. Largely thanks to one person’s efforts, React applications are also very testable which is not true of everything.

Add those together and you get something worth more than any benchmark. A React application can be written well, be close to bug free, be fast and be a reasonable foundation for a business. It very often isn’t any of those things and the important part is that nothing about the framework is stopping you.

This is exactly why a smaller, faster library usually isn’t an alternative. A developer using it will be less capable than a developer using React, not because they’re worse but because the tooling around it isn’t there. There’s no debugger built for it, no testing story anybody has refined and no stack of answers from people who hit the same thing last year and wrote it down. You’re doing the same work with fewer tools and less built up knowledge and the three kilobytes will not make up for it.

React isn’t the code that ends up in the bundle and it’s everything around the code and almost all of that is invisible in the comparison people publish.

So if you’re building something in this space and you want it adopted, shaving another millisecond or another tenth of a kilobyte is not the work. The gap between you and the incumbent is developer experience and it’s measured in documentation, tooling and years. That’s a much less exciting project than optimising the diffing algorithm and it’s the one that decides whether anybody can use what you built.

The same thing plays out with languages and databases and anything else people compare on a single axis. The winner is usually whichever one has had the most person-years poured into the boring surrounding work and that’s very hard to catch up on because it accrues rather than being built.

Speed is a feature you can add in a quarter. An ecosystem is not.

If you’re picking for a project rather than building one, the useful question is what happens when you get stuck at four in the afternoon on something odd. With a mature ecosystem you search a phrase and find three people who hit it. With a lean one you read the source. Both are fine. Only one of them is fine every week for two years.