Photo by redcharlie on Unsplash
After Years Working in Tech I Am Tired of Fighting About Frameworks
M. Zakyuddin Munziri
@zakiego
I am tired of those fights.
After years working in tech, I have seen the same arguments loop. People treat frameworks like identity. Tweets become wars. Meetings become debates about taste. Meanwhile the product and users wait.
Yes, some frameworks are objectively worse. But most popular frameworks are close enough. The real differences matter in context, not as absolute winners. One framework may bootstrap faster. Another may offer slightly nicer ergonomics for a specific pattern. Those are real tradeoffs, but they are rarely the cliff that decides success or failure.
Why the fights happen
Framework debates are noisy for two main reasons. First, tools become identity. Choosing a framework signals experience, taste, or belonging to a tribe. Second, hype amplifies small differences. New libraries promise to solve a feeling people already have. Old libraries get blamed for problems that are actually process issues.
When that emotional layer appears, the conversation leaves tradeoffs and enters religion. That wastes time and morale.
Most frameworks are 11 to 14 on a 1 to 20 scale
In practice, frameworks converge on the same core problems: routing, state management, rendering, lifecycle, and data flow. Implementation details differ. APIs differ. But after the first months of a project, the dominant factors are not the framework name.
What actually moves outcomes are the human systems around the framework: how the team reviews code, who owns runtime behavior, how testing and observability are structured, and how changes are shipped and rolled back. These are the things that determine velocity and stability, not whether library A uses hooks or class components or some different router API.
Preference is fine. Mandate is not
I have favorites. I will explain why I prefer them. I will point out patterns I like and antipatterns I avoid.
But preference should not become a mandate without reason. Good teams pick a default and document the reason. They make the decision reversible. They write down the tradeoffs so newcomers understand the cost. They allow exceptions with a short approval path when the case is strong.
That keeps the conversation practical. It moves the team from tribal debate into engineering tradeoffs.
Frameworks can be learned and patched
Frameworks are tools, not doctrines. If a framework lacks a feature you need, you can do one of three realistic things. First, accept the tradeoff and avoid the pattern that triggers the weakness. Second, add a small adapter or wrapper that provides the contract you want. Third, document the pattern so the team uses a consistent approach.
These are engineering moves. They are boring. They work. They scale much better than convincing the whole company to switch stacks for a minor ergonomic win.
How I recommend teams decide fast and without drama
Make the decision process explicit. Answer three practical questions and document them.
- What problem are we solving and why does this framework help us solve it.
- What are the measurable costs we accept if we choose this framework.
- How can we reverse or mitigate the choice if it causes problems.
If those answers are clear, the framework choice is usually fine. If you cannot answer them, the debate is just noise.
When the argument is worth it
There are real cases that deserve a fight. Extreme performance constraints, strict compliance requirements, or massive legacy debt are legitimate reasons to escalate. In those cases, argue with data and clear metrics. Show the difference in maintenance cost, operational overhead, or latency under real load. But those situations are less common than the wars on Twitter make them seem.
Closing
I still care about good tools. I still care about tradeoffs. I am not indifferent. I am only tired of converting technical taste into team friction.
Framework choice is about context, not character. Teach the tradeoffs, document the patterns, patch the gaps. Then stop arguing and get back to building useful things.
If the debate persists, try this with your team: pick a default, write one paragraph explaining why, set a short review window, and move on. You will get more done.
