Comment by andrewingram 3 days ago
Yeah, I think both these are true:
1. React is bigger and slower than it needs to be. There are likely better choices today. 2. Most websites will be bigger and slower than they need to be due to the endless September of new devs, and the rarity of being given space to focus on size/performance. As React is popular, it means even if React was tiny and fast, these websites would still be slow.
I understand your answer is in good faith, but it still sounds like the same generic answer given when someone questions the engineering quality of any other popular product or service.
The fact is that plenty of teams are mature and professional and yet most software still suffers from bloat, slowness, bugs. Why would React be different?
Preact, for comparison, is only 5kb or so, and has almost 1:1 feature parity. It's not fully drop-in without the compat, and even experienced React devs can nitpick about it, but that's not the point: the mere fact that it exists and gets the job done is enough to raise doubts about the need for React to be quite big.
Does React need to lose weight? Maybe, maybe not. But I don't think it's good to shut down those discussions.
I think the same generic answer _does_ apply to most mature projects. Libraries like these should be approached like discussions about starting over in mature software projects; "this time we'll do it correctly", or "this framework is much simpler". This applies very much to libraries such as these.
When the complexity is low, projects are easy to learn, maintain and handle. That really makes them seem better and have advantages – advantages like a much reduced bundle size. But these new setups just don't do the same thing. It's a shell of what the old project did, as it's missing solutions for hundreds of edge-cases and other requirements that were tackled by the mature many-year old project that is maintained by some of the best developers. I'm sure React has a bit of bloat, but I'm willing to trust the React team that the vast majority of it is there for a reason. It might also be the cost of building on top of a very mature solution.
Would you not shut such a discussion down when someone new in the team proposes a complete rewrite?
Preact does not have 1:1 feature parity, if it had it would have been much more widely used (who wouldn't want a free filesize reduction?). Preact has plenty of issues, which is why it isn't as widely used.
No, I would not shut down discussions. I appreciate new points of view, and I’m fine with being challenged. I would especially not shut down discussions when my assumptions are nothing but a hunch.
> Preact does not have 1:1 feature parity, if it had it would have been much more widely used
Like another poster said, this is a logical error. Preact is fully featured.
Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.
> a single component outweighing an entire app feels fundamentally broken.
I think this is an overly dramatic take. Of course react has a fixed overhead. If all you're deploying is the single button, then that overhead is for no benefit. But the overhead gets amortized over your entire app, which most likely has thousands of components. This is like a microbenchmark which only measures the static overhead. Not indicative of a real app.
There's an entire cottage industry of "react" but smaller frameworks out there. Somehow, none of them have caught on.
Preact is the one I'd go for if I wanted a smaller react because it's quite mature and it provides the same API.
> a single component outweighing an entire app feels fundamentally broken
It just doesn't to me, understanding that in react-land, a single component and an entire app will have roughly equivalent size, if you're not pulling in any other dependencies.
No one (I hope) would ever use react for a single button, so it feels like an unhelpful comparison.
I don't think that is fundamentally broken. React is just not the right technology for a single button, and it's not trying to be.
If you tried to use photolitography (the technology used to print the circuits in microprocessors) to do tattoos... well it could probably work, but it would be highly inefficient and expensive and bad.
React is for complex web applications, and it I don't think it's a very valid criticism to say that it is bad for a different use case. To some extent, the React community may have over-promoted React as the final web-dev framework, but that's also a mistake.
In any case, kudos on creating Nue, looks really cool, I'll keep an eye on it ;)
Compare React and Preact:
I use Preact often and very, very rarely run into an issue that justifies React being almost 20x the size.
Is it really React or the stuff it lets you bring in? Many React apps have at least one big widget set (say MUI or reactstrap or …) and then a number of “best of breede” components that do various things. It’s rare for components to be styled with plain CSS these days so you probably have to bring in Emotion and styled-components and Tailwind and …. It is all code that goes into the bundle and it’s a burden on your mind because these are all leaky abstractions and don’t absolve you of understanding CSS.
A someone who's been developing for the web for a living since the late 1990s, I agree that nothing absolves the web developer of the need to understand web fundamentals. But laying blame for bloated SPAs at React's feet is misplaced. With SSR, you can ship React apps that work with JS disabled. And with static extraction (a la vanilla-extract) you can do CSS-in-JS with 0 runtime overhead. Being mindful of bundle size and user-perceived performance is essential. For those that pay attention and leverage the web properly as a platform, amazing performance (and capabilities / UX) with React is achievable. See https://Remix.run.
If Preact truly was as feature complete as React, it would be used by everyone by now – it's old enough for most teams to be aware of it. The fact that it isn't widely used is case in point.
> If Preact truly was as feature complete as React, it would be used by everyone by now
That's a false logical conclusion.
Preact (and others, like Svelte and Solid) are not only "as feature complete as React", they don't need some of the features of React (hooks are unnecessary when you have proper reactivity) and they are better at certain features (like SSR).
People using or not using them has nothing to do with feature completeness.
Why would React be bigger and slower than it needs to be? It's a very mature project with a professional development team behind it, I'm sure we can trust them to tackle whatever unnecessary bloat they may have. I think we should be able to trust that anything that is in there serves a purpose, and that it serves hundreds of niche edge-cases that someone will eventually run into but are non-obvious until it's widely used.
These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.