I recently read Loren Stewart’s piece, React Won by Default – And It’s Killing Frontend Innovation. It resonated with me. As someone who has specialized in React for years, I’ve seen firsthand how React became the default choice for frontend work — not always because it was the right tool, but because it was the safe one. Hiring pools, ecosystem maturity, and inertia keep it on top.
Teams build more projects with React by default. That creates more demand for React developers. Demand pushes more developers to learn it, which drives even more adoption. The cycle feeds itself.
And yet, React comes with baggage: hooks that demand careful dependency management, bundles that grow heavy, and patterns that create mental overhead.
React won by default, while frameworks like Svelte or Solid failed to attract large communities — not because they’re bad, but because they lacked a killer feature that convinced developers to switch personally or fight for corporate adoption. React became the comfort zone of frontend developers, and for good reason.
This was on my mind when I revisited Angular. After a few failed attempts years ago (shoutout to that Pluralsight course that nearly scared me off for good), I dug in again — and realized something: React won by default, but Angular lost by design.
Angular’s Core Trade-offs
Angular is not a bad framework. In some contexts, it’s excellent. It gives you batteries included: routing, forms, dependency injection, a well-structured CLI, and an opinionated architecture that keeps large teams aligned. For enterprise-scale projects, that’s gold. You’re not stuck cobbling together your own meta-framework on top of React.
But those strengths are also weaknesses. Angular demands buy-in to its way of doing things. You don’t get the freedom of React’s composability or ecosystem sprawl. The barrier to entry is higher, the learning curve steeper, and the framework itself feels heavy if you’re used to the “just a library” mindset.
In short: Angular deliberately chose rigidity and structure, while React left things open. That design choice made Angular less appealing to the broader frontend crowd, who wanted flexibility and fast iteration.
Why Angular Lost
Angular’s opinions were meant to solve decision fatigue. Ironically, they made the framework less approachable. Developers (myself included) didn’t want to stop and learn a full-blown architecture when React let us npm install a few libraries and ship.
Angular became associated with big, slow-moving enterprise apps — the opposite of what most frontend developers wanted.
So while React spread by inertia, Angular limited itself by design. That doesn’t make Angular bad — it just made it niche. The trade-offs were conscious.
My Take on React (And Why I’m Not Anti-React)
I agree with much of what Loren wrote. React isn’t perfect, and pretending otherwise slows down innovation. But I don’t hate React.
I still think React’s model of UI as a function of state was a breakthrough, and I use it daily. The issue is less React itself and more the fact that we default to React without stopping to ask if it’s the best fit.
Angular reminded me of that. It’s not the right tool for most of my projects, but for large teams or enterprise-scale apps, it absolutely makes sense. The fact that Angular chose a path — structure, rigidity, enterprise alignment — is admirable, even if it cost them mainstream adoption.
Closing Thought
The lesson isn’t “React good, Angular bad.” It’s that we shouldn’t let defaults make our decisions for us. React won by default. Angular lost by design. But both point to the same truth: choosing intentionally — based on the actual constraints of our projects — is the only way frontend can move forward.