maybe we don't need more frameworks

there are alot of articles about this topic out there, but i am going to write about it too! 😂 i've been writing TypeScript for long enough to have watched the same cycle repeat itself at least three times. a new framework drops. twitter erupts. a thousand "getting started" tutorials appear within a week. six months later, half the people who adopted it are quietly maintaining it while secretly wishing they'd stuck with what they had.

we call this framework fatigue, and we've been diagnosing it like it's a personal failing. it's not. it's structural. and the data backs it up.

the numbers behind the noise

here's something from the State of JavaScript 2025 survey that should reframe the entire conversation: the average respondent has used only 2.6 frontend frameworks over their entire career. the survey puts it directly; "the image of the burned-out web developer jumping from framework to framework on a monthly basis isn't quite accurate anymore." Strapi

the ecosystem is not moving as fast as the discourse makes it feel. what's actually happening is that a small, loud group of early adopters are generating enormous amounts of content about tools that the majority of working developers haven't touched yet and probably won't. the feeling of fatigue comes from the noise, not the migration.

but here's the problem: the noise still has real costs. the average framework has a phase of peak popularity of 3 to 5 years, followed by years of slow decline as people maintain legacy applications but move to newer frameworks for new work. npm so even if you personally don't jump every cycle, your codebase eventually inherits decisions made during the hype phase. you end up maintaining the legacy of someone else's excitement.

what abstraction costs you actually

every framework is an abstraction layer. every abstraction layer is a tax.

the tax is real in at least three ways. first, there's the cognitive overhead. you're not just learning the abstraction's API. you're learning its mental model, its failure modes, its community conventions, and its opinions about problems you may not have. a new framework doesn't just add syntax to learn. it adds a whole epistemology.

second, there's the dependency chain risk. npm micro-packages, which encapsulate and delegate complex tasks to other packages, can have long dependency chains and incur just as much usage cost as other packages despite their minimal appearance. arXiv layer enough abstractions on top of each other and you're no longer in control of your stack in any meaningful sense. you're just hoping nobody breaks a package three levels down.

third, there's what you might call the oracle problem. when you combine unfamiliar technologies with AI-generated code, you're not just adding unknowns, you're multiplying them. you don't know if the framework choice is appropriate. you don't know if the AI's implementation follows best practices. Brethorsting in 2026, where a significant portion of the code most of us write is at least partially AI-assisted, this is a real compounding risk. an unfamiliar framework combined with AI hallucinations is a bad combination.

the tools promised to abstract away complexity. what they actually did was relocate it.

the learning cost nobody accounts for

when a team evaluates a new framework, they usually do a proof-of-concept. someone builds a todo app or a dashboard in it over a weekend, it works great, and the team ships the decision. what they don't account for is the long tail.

the learning cost of a framework isn't the first two weeks. it's the next two years. it's the edge case you hit six months in that has two StackOverflow answers, both from 2021, both for a version that no longer exists. it's the migration guide that assumes you're starting from scratch. it's the architectural decision you made in month one that you realize in month fourteen was the wrong interpretation of the docs.

Dan McKinley's framing was about cognitive overhead for your team. every exotic technology choice means more documentation, more debugging, more onboarding friction. often this skill becomes "islanded", only a select group of people understands it. Jonathannen i've watched this happen. one person becomes the framework expert by default. they leave, or burn out, or just get tired of being the one person who knows how the router works, and you get a knowledge gap that costs real engineering hours to recover from.

the framework that looked like leverage in month one becomes a liability by year two.

why boring technology keeps winning

there's a concept that gets brought up every few years and then forgotten again, which is probably fitting given the topic: every company gets about three innovation tokens. you can spend these however you want, but the supply is fixed for a long while. mindful choice of technology gives engineering minds real freedom, the freedom to contemplate bigger questions. Mcfunley

McKinley wrote that in 2015. it's more true now, not less.

boring tech has survived years of production use. it has documentation, Stack Overflow threads, GitHub issues, and real-world success stories. there's a bigger talent pool and faster onboarding. DEV Community PostgreSQL is 28 years old. it's not exciting. it also handles concurrent writes, has a mature extension ecosystem, and has documentation deep enough that almost any problem you'll hit has been written about somewhere. when something breaks, you want boring.

most LLMs are trained on the internet. this means established, well-documented, stable technologies are extremely well represented, SQL, PostgreSQL, Redis, REST, React. the boring stuff has millions of examples, repos, tutorials, and battle-tested patterns baked into the model weights. Jonathannen in other words, the boring choice is also the AI-native choice. you can actually catch when the AI is wrong, because you know the domain well enough to evaluate its output.

look at pieter levels, who maintains seven products solo. every single one uses the same PHP/SQLite/jQuery stack. he copies patterns across products, shares code between them, and deploys changes rapidly. SoftwareSeni that sounds absurd from the outside. seven products on jQuery? but his profit margin is above 80%. he's not being inefficient. he's being strategically boring.

stack overflow runs on a monolith. shopify runs on a monolith. unless you're planning to onboard the entire population of brazil tomorrow, a boring monolith is fine. DEV Community

so what do we do

i'm not arguing that you should never adopt new frameworks. i'm arguing that the bar should be higher than "it has good DX" or "the benchmarks look nice" or "the community is excited about it."

the question to ask before adopting anything new is this: what specific problem does my team have right now that the existing stack cannot solve, and is this framework the simplest possible solution to that problem?

the choice of technology should free up engineers to contemplate larger, more important issues instead of bogging down in how to use new tech or reconcile multiple technology stacks. Jadon that's the actual goal. every hour your team spends understanding why the router is doing something unexpected is an hour not spent on the problem your users actually care about.

the frameworks that survive long enough to become boring are the ones that solved real problems well enough that nobody wanted to throw them away. react is 12 years old and still dominant not because it's the most elegant solution to UI rendering, but because it has accumulated enough production knowledge, ecosystem tooling, and institutional familiarity that switching costs are real. that's not a lock-in story. that's stability.

close

the framework ecosystem will keep producing new entries. that's fine. healthy, even. the experimentation at the edges is how we learn what works before standardizing on it.

but most of us are not at the edges. most of us are in the middle, building things that need to work, be maintained, and be understood by whoever inherits the codebase when we're gone. for that work, boring is a feature.

the next time a new framework hits your timeline and the discourse starts building, ask yourself what problem it's solving and whether that problem is actually yours. most of the time, the answer will be no. and the time you would have spent learning it is better spent going deeper on what you already have.

that's not pessimism. that's just engineering.

want fewer frameworks in your inbox?

one email a week. tools worth using, ideas worth stealing, and the occasional opinion nobody asked for.