Framework monoculture is a psychology problem as much as a tech problem. When one approach becomes “how things are done,” we unconsciously defend it even when standards would give us a healthier, more interoperable ecosystem. Psychologists call this reflex System Justification. Naming it helps us steer toward a standards-first future without turning the discussion into a framework war.
I’ve been sitting with this idea for a while, especially in React-centric conversations where familiarity is often treated as proof. Over the past year, a run of blog posts, conference talks, YouTube videos, and a few interactions with standards-oriented groups nudged me to finally write this down. This isn’t a takedown of any project or community; it’s a look at a human reflex many of us share when our tools become our identity.
My aim here is simple: explain the psychology (briefly), show how it maps to front-end habits, name the quiet costs of monoculture, and offer a pragmatic path toward a standards-first posture that still meets teams where they are.
System Justification
In the 1990s, social psychologists (notably John Jost and Mahzarin Banaji) described System Justification Theory (SJT) as the idea that people are motivated to see existing arrangements as legitimate, fair, and desirable even when those arrangements have obvious downsides or are downright harmful. In other words, it’s a matter of familiarity. Individuals and groups defend the status quo because it reduces uncertainty, protects identity, and keeps members aligned with their groups.
SJT highlights three motives that drive this defense:
- Epistemic: The comfort of being right. Clear rules and familiar patterns feel safer than ambiguity.
- Existential: The comfort of safety. It’s less frightening to believe the world you’ve invested in is basically true, good, and beautiful.
- Relational: The comfort of acceptance. Agreeing with your community keeps you inside the circle.
If you scan history, you’ll spot the same pattern over and over again:
- Early resistance to handwashing in medicine (the “Semmelweis reflex”).
- Decades of public minimization around tobacco harms.
- Long, loud debates over seatbelts and other safety standards.
- “Separate but equal” as a rationale for inequality masked as order.
- And many more (see appendix)…
None of these debates were purely about evidence; they were about identity, habit, and social standing.
Now translate that to the web. When a single toolset becomes the default, we don’t just prefer it, we build narratives that justify it. And that’s when a tool quietly becomes a gate or even a destructive force.
Subtle Reflex
System justification doesn’t announce itself. It shows up as common-sense statements, subtle status signals, and “everyone knows” assumptions:
- “This is how real apps are built.” The present method masquerades as natural law. Alternatives become “experimental,” “academic,” “toy,” or “fringe” even when they align with widely adopted standards.
- “Standards are idealistic; we ship.” Shipping is good. But this framing sneaks in a false tradeoff: standards are painted as purity projects rather than the bedrock that lets different teams, tools, and runtimes collaborate without friction.
- “Our audience is modern, so the costs don’t matter.” Hidden costs (bundle weight, device inequity, hydration overhead, portability constraints) get discounted as someone else’s problem. Often that tends to be users with older devices, spotty networks, or that require assistive technology.
- “Everyone on the team knows this stack.” Familiarity becomes proof of superiority. The fact that a community is large and helpful (a real benefit!) mutates into the claim that alternatives are unworthy.
- “If it were better, we’d already be doing it.” This is injunctification: confusing “what is” with “what should be.” At this point, the comfort of the status quo has become its own argument.
Behind these lines are those three motives I mentioned before: the desire to be right, safe, and accepted. Notice how much of the rhetoric protects identity (“we’re experts in X”) and group cohesion (“this is who we are”) rather than debating technical merit or user impact.
Quiet Costs
When one approach becomes the unexamined default, you don’t just get consistency, you also accumulate opportunity costs that are easy to miss in the moment:
- Slower standards adoption. If your core primitives exist only inside a single framework abstraction, other surfaces can’t reuse them without translation. That discourages cross-project collaboration and fragments the commonality that standards provide.
- Less innovation. Monoculture makes it harder to try architecture patterns that assume standards first (progressive enhancement, islands, simpler render paths). The conversation shifts from “what does the platform already give us?” to “how do we shoehorn the platform into our preselected model?”
- Reduced portability and value. Work tightly bound to one frontend framework is harder to move between products, partners, and future platforms. Today’s convenience turns into tomorrow’s migration tax.
- Fragility in supply chains. When large chunks of your UI or data flow depend on a specific ecosystem, you inherit its release cadence, deprecations, and politics. If that ecosystem’s priorities diverge from yours, you feel it.
- Talent pipeline brittleness. Hiring “only X framework” narrows who can contribute. Onboarding becomes about memorizing a house style instead of leveraging the web and public contracts. That’s great until you need people who didn’t grow up inside the same assumptions.
- User-shifted costs. Developer convenience is meaningful, but when it consistently beats standards-based reuse and progressive delivery, users pay in bandwidth, energy, accessibility, and responsiveness.
These rarely show up in a single PR, but they accumulate as costly drift.
Standards First
This isn’t a call to abandon frameworks. It’s a call to re-center standards as the foundation and treat frameworks as adapters that improve ergonomics where helpful. Think of it as a “shift left” of front-end.
- Publish primitives as standard-compliant units. Think clear public contracts: documented interfaces, events, and styling hooks that any framework can build on.
- Offer adapters for popular stacks. Keep the ergonomic sugar where teams want it without making the framework adapter the source of truth.
- Document the contract, not the adapter. Make the standard interface the canonical reference. Adapters will come and go but the contract should endure.
- Measure portability. Track reuse across projects/frameworks, the thinness of adapters (no duplicated logic), and the performance and accessibility characteristics of the standard layer.
The goal isn’t to win a framework debate. It’s to make your work lean, portable, and future friendly.
Objections…Answered
Here are a few common objections I’ve heard over the years, each accompanied by a brief reply.
- “Developer experience will get worse.” Good DX belongs at the edges. Keep rich types, ergonomics, and editor integrations in your adapters, but anchor correctness, semantics, and accessibility in the standards-level contract. You’re moving convenience, not sacrificing it.
- “Standards move too slowly.” Stability is a feature at the primitive layer. You can still innovate rapidly in composition, architecture, and tooling. Just don’t fork the base. When standards evolve, your contract benefits everywhere at once instead of patch-by-patch in each framework.
- “This will slow shipping.” The first few primitives take discipline. After that, reuse pays compound interest especially across multiple apps or surfaces. If you measure total delivery (including maintenance and cross-team portability), standards-first usually wins on time.
- “No one is asking for this.” Portability is like backups: ignored until it isn’t. Partners, acquisitions, re-platforming, and new surfaces make “runs anywhere” suddenly priceless. You don’t get that value by accident, only by design.
- “Our team doesn’t know how to do it.” Start small. Write one simple, well-documented contract and a pair of adapters. Share the recipe. Most of the skill is in writing clear interfaces and testing behavior, skills your team already has.
- “We’ll split the community.” Standards-first is a unifier. It invites more communities to participate because the core is neutral. The conversation shifts from “which framework is allowed?” to “how do we make the contract great?”
- “The performance gains aren’t guaranteed.” True…and that’s why you measure user-visible outcomes (latency to first interaction, responsiveness, energy use) at the standard layer. If an adapter adds weight, it’s localized and replaceable; the base remains lean.
- “Security and compliance will be harder.” The opposite. A single, well-documented contract simplifies auditing, testing, and threat modeling. You assess the primitive once and reuse the assurance everywhere, instead of auditing n copies of the same idea.
Default Defense
Here are some practical ways to guard against a default framework monoculture, whether on your keyboard, in a design review, or during a meeting.
Spot the Tell
Listen for “comfort” language. It’s a red flag that should prompt us to pause and examine. Here are a few common patterns:
- Injunctification “That’s just how it’s done.” or “Real apps do X.”
- Appeal to Familiarity “Everyone on our team knows this already.”
- Status Through Popularity “The ecosystem is huge, so it must be the best.”
- Minimizing User Costs “Our users are on modern devices anyway.”
- False Dichotomy “Standards are idealistic; we ship.”
- Sunk Cost “We’ve already invested too much to change now.”
- Exaggeration “If we don’t do it this way, everything else breaks.”
- Security Blanket “Compliance will hate anything new.”
- Preemptive Defeat “If this were better, we’d already be doing it.”
When you hear one of these, ask: Is this defending identity or describing reality?
Ask Yourself
Use the following as a mental checklist to help yourself steer clear of the default trap:
- Counterfactual Would I still believe this if my preferred framework/tool didn’t exist?
- User-first Where do users pay for this choice (latency, accessibility, bandwidth, portability)?
- Contract Can I articulate the standard-level contract independent of any framework?
- Opportunity What future paths does this decision close? What does it keep open?
- Evidence Do we have a measured outcome, or just a story that feels safe?
- Reversibility If we’re wrong, how hard is this to undo?
- Portability Could a team using another framework consume this work without needing to rewrite it?
Reframe It
Try to turn status-quo defenses into standards-first questions without picking a fight.
- From: “This is how we build apps.” To: “What’s the smallest standard contract here, and how would frameworks map to it?”
- From: “DX will tank if we move away from X.” To: “How do we keep great DX at the edges while grounding behavior in a standard interface?”
- From: “No one’s asking for portability.” To: “Which upcoming surfaces/partners would benefit if this were portable by default?”
- From: “Security won’t allow it.” To: “Can we write the contract so security can audit it once and bless all adapters?”
- From: “It’s too late to change.” To: “What thin seam lets us pilot a standard-level primitive alongside what we have?”
- From: “This pattern is proven; everyone uses it.” To: “Popularity does not equal portability. Can we prove the contract stands on its own?”
- From: “Performance is fine on modern phones.” To: “Let’s test on slow hardware and unreliable networks. If the framework adapter adds cost, can the standard base stay lean?”
Final Thoughts
This isn’t about shaming individual or team preferences. It’s about noticing when preference hardens into dogma, and gently pivoting the conversation back to standards, contracts, and users.
Frameworks come and go; the web remains. If we can notice the human urge to defend “how we do things” simply because it’s how we do things, we can aim that energy at building a stronger foundation: standards first, adapters as needed, and design always.
If you maintain a design system, library, or toolkit, consider publishing your primitives to a clear, standards-oriented contract and inviting framework and tool adapter authors to the table. That’s not anti-framework; it’s a pro-web approach that widens the path for everyone.
Appendix: Historical SJT Examples
A few examples of SJT in recent history.
Medicine and Science
- Germ theory and asepsis (post-Semmelweis) Early pushback defended established routines and senior authority. Tell: “We’ve always done it this way; outcomes are fine.”
- Stomach ulcers (H. pylori) The “stress/spice” story persisted long after bacterial evidence emerged. Tell: Familiar theory felt truer than revision.
- Bloodletting as standard care Centuries of inertial legitimacy despite mounting counterevidence. Tell: Tradition = truth.
- Lobotomy in psychiatry Entrenched as “last resort” therapy before antipsychotics, long past ethical/clinical doubts. Tell: Harm reframed as necessary tradeoff.
Public Health and Safety
- Smoking in public spaces “Personal freedom” and “ventilation is enough” narratives resisted smoke-free rules. Tell: Costs shifted to bystanders, normalized as choice.
- Leaded gasoline Industry reassurances delayed phase-out despite environmental/health data. Tell: System seen as safe because it’s ubiquitous.
- Asbestos “Proper handling makes it fine” slowed bans. Tell: Diffusion of responsibility (“we follow the guidelines”).
- Seatbelts, airbags, helmets “Restrictive,” “unsafe in rare cases,” “I’m a careful driver.” Tell: Anecdotes outrank data.
Environment and Energy
- CFCs and the ozone hole Early minimization framed changes as economically catastrophic. Tell: “Not proven” + “too costly” = defend status quo.
- Climate change denialism Identity, jobs, and regional economies tie to existing energy systems. Tell: Evidence filtered through group belonging.
Civil Rights and Social Policy
- “Separate but equal” Inequality rationalized as order and tradition. Tell: Stability over disruption.
- Child labor Framed as “builds character” and economic necessity before reforms. Tell: Harms recast as virtues.
Technology and Work
- “Office-only” culture Remote work dismissed as unserious or unproductive. Tell: Familiar practice = proof; counterexamples waved away.
- Proprietary file formats “Ecosystem integration” used to justify lock-in over open standards. Tell: Convenience for insiders outweighs portability for everyone.