Introduction
TL;DR
The Dead Framework Theory, introduced by Google’s Paul Kinlan, describes a fundamental shift in how web technologies achieve dominance in the AI era. New web frameworks now face a self-reinforcing feedback loop: React dominates the web → LLMs learn from React code → AI tools output React by default → more React sites are built → LLMs learn even more React. This cycle makes competing frameworks effectively “dead on arrival.” New frameworks require 12-18 months minimum to enter LLM training datasets, but during that period, the React ecosystem generates 10+ million additional sites. The theory reveals that technological superiority alone is no longer sufficient—what matters is presence in LLM training data, AI tool prompts, and developer mindshare.
Context and the New Reality
The web development landscape has undergone a paradigm shift with the rise of Large Language Models and AI coding tools. For decades, new frameworks could gain adoption through technical excellence, developer preference, and community adoption. React, Angular, Vue.js, and Svelte competed on merit. Today, that’s no longer how the game works.
React hasn’t simply won—it has become the de facto web platform. This transformation isn’t primarily due to technical superiority, but rather because LLM-based coding tools default to outputting React code. When tools like Replit and Bolt hardcode React into their system prompts, they’re not making a preference statement—they’re responding to market demand for maintainable code that existing developers understand.
React’s Transformation: From Framework to Platform
The Dominance Metrics
Recent data paints a striking picture of React’s position. In 2024, 42% of developers actively use React, making it the most widely adopted framework. The top 1 million websites show 12-18% React adoption rates, but the growth story becomes clearer in new deployments: over 13 million new sites were deployed with React in a single 12-month period.
Critically, this isn’t because React is technically superior to alternatives like Svelte or Solid. Rather, it’s because React has become the expected default across the entire development ecosystem. When a junior developer asks an AI tool to build a web app, it outputs React. When a technical team considers options, they recognize React. When documentation and tutorials are created, they feature React.
Why it matters: React’s position has transcended typical framework adoption patterns. It’s no longer in direct competition—it’s become the assumed baseline. Competing against React now means competing against infrastructure.
The Platform Phenomenon
What does it mean for a framework to become a platform? In traditional software terminology, a platform provides foundational services upon which other applications are built. By this measure, React has achieved platform status not through architectural innovation, but through ecosystem pervasiveness.
Libraries, tools, documentation, tutorials, and developer experience investments have created a gravity well. New developers entering web development typically encounter React first. Existing developers have years of React experience and frameworks built around it. Companies have established codebases, team knowledge, and hiring practices centered on React.
The shift from “framework” to “platform” means that alternative frameworks are no longer competing on technical grounds alone. They’re competing against a comprehensive ecosystem, trained developer population, and deeply established patterns. This transition, catalyzed by LLM adoption, has fundamentally changed the rules of framework competition.
The Self-Reinforcing Feedback Loops
Understanding the Dual Loop Structure
The Dead Framework Theory’s central insight is that two interconnected feedback loops reinforce each other continuously:
Loop 1: Web Data → LLM Training → Code Generation → Deployment
The first feedback loop operates at the data and model level:
- React dominates the existing web (13+ million new sites deployed monthly)
- LLMs train on existing web data, absorbing React patterns
- LLMs generate React code by statistical default
- LLM-generated sites deploy with React
- More React sites exist in the web corpus for future training cycles
- Return to step 2
This loop is statistically self-reinforcing. When React represents 12-18% of the top million websites, LLM training datasets become skewed toward React patterns. This bias then manifests in generation—models output React not from explicit instruction, but from statistical patterns learned during training.
Loop 2: Developer Preference → Tool Defaults → Adoption Demand → More Preference
The second loop operates at the human and tool level:
- React dominates developer consciousness and preferences
- IDE and AI tools (GitHub Copilot, Replit, Bolt) explicitly prioritize React in their system prompts
- These tools request LLMs to generate React code by default
- New sites built through AI assistance use React
- More React sites exist in the wild, driving user demand for React-fluent tools
- Return to step 1
This loop is driven by market pressures. Tool vendors cannot ignore that developers recognize and prefer React. Defaulting to React in system prompts provides better outcomes for end users and reduces support burden.
The Compounding Effect
These loops don’t operate independently—they reinforce each other. When tools output React, new sites are built with React, which enters the web corpus, which influences LLM training, which further biases tool outputs toward React. The effect is amplified with each cycle.
Evidence of this loop exists in token consumption patterns. OpenRouter token consumption growth curves almost perfectly mirror React deployment growth curves—not definitive proof of causation, but striking temporal alignment.
Why it matters: Traditional competitive dynamics assumed technological superiority could overcome incumbent advantages. These feedback loops make that assumption obsolete. Displacement requires not just better technology, but simultaneous control over training data, tool defaults, and developer perception.
The LLM Training Data Requirement: The 12-18 Month Barrier
When Absence from Training Data Means Non-Existence
A critical insight of the Dead Framework Theory is stark: if your framework isn’t in LLM training data, it doesn’t exist for most developers. Not strategically, not potentially—literally, in practice. If an LLM model’s training cutoff precedes a technology’s significant adoption, that technology remains invisible to the model until the next training cycle.
Paul Kinlan’s recent experience illustrates this precisely. When building a Chrome Extension using Claude to test Chrome’s new LanguageModel.create() API, Claude generated code using the deprecated self.ai.languageModel API from six months prior. The newer API hadn’t yet been included in Claude’s training data.
The Timeline Problem
The timing dynamics are asymmetric and brutal:
New Web Platform Features
- Real-world adoption: 0-6 months before LLM training cutoff
- Time in training data: 12-18 months minimum wait for next cycle
- Total latency: 12-24+ months before statistically meaningful representation
New Web Frameworks
- Real-world adoption: 0-6 months before LLM training cutoff
- Time in training data: 12-18 months minimum
- Added friction: Must also achieve sufficient adoption to be statistically meaningful in training data
React Patterns
- Historical depth: 10+ years of accumulated examples
- Training data representation: Extensive coverage across all recent training cycles
- Competitive advantage: Overwhelming statistical superiority in all modern LLM models
This asymmetry is devastating for new technologies. By the time new technology achieves meaningful LLM representation (requiring actual deployment and usage), the established technology has already generated another 10+ million implementations in the wild.
Concrete Barriers to Entry
The barriers manifest across three dimensions:
Training Data Barrier: A new framework must exist in the wild for 6+ months with meaningful adoption before being included in training data. LLM training cycles typically occur annually at best. The next training cycle still needs months of model training and evaluation before deployment. Net result: 12-18 months minimum before LLM availability.
Tool Integration Barrier: AI coding tools like Replit and Bolt have hardcoded React into their system prompts. Changing these defaults requires tool developers to be convinced that the change benefits users. Since existing developers recognize React, alternatives create friction. Tool vendors face market pressure to default to React.
Developer Adoption Barrier: Even when new frameworks appear in LLM training data, developers must explicitly request them, or discover them through other channels. The default output from tools will remain React unless users specifically override. Initial adoption requires non-zero user effort.
Why it matters: These barriers aren’t technical—they’re structural. No engineering excellence can overcome them. The barriers exist in data distribution, market incentives, and human behavior, not in code quality.
Web Platform APIs and the Same Fate
Browsers Also Face the Feedback Loop
Surprisingly, this problem isn’t limited to web frameworks. New browser APIs and web platform features face identical challenges.
Consider how CSS Nesting reached browsers. After identifying that developers frequently used preprocessors like Sass for nesting, browser teams initiated standardization. Years of standards work followed. CSS Nesting was eventually implemented across browsers. Developers should naturally adopt it.
But they don’t.
LLMs continue generating Sass and CSS-in-JS solutions from tools like styled-components and Tailwind instead. Why does the newer, native browser feature lose to older preprocessing patterns?
- LLMs learned old patterns: Sass has 15+ years of examples; CSS Nesting has 1-2 years
- Frameworks already work: React developers have established patterns and ecosystem libraries using existing CSS approaches
- Ecosystem is built: Thousands of React component libraries use established CSS patterns
- No motivation to switch: New platform features don’t improve end-user experience significantly
A concrete example: developers need carousel components. Browsers could implement native carousels. But thousands of existing libraries (Swiper, Slick, React Slick) already solve this, and LLMs know how to generate them. The labor of switching existing codebase patterns, updating team knowledge, and disrupting proven workflows doesn’t deliver observable user benefits.
The Fundamental Feature Distinction
This leads to a critical insight: only truly fundamental platform features—those impossible to build in userland—will be adopted.
Fundamental features that justify adoption:
- Multi-page View Transitions (new navigation paradigm)
- WebGPU (entirely new computing model)
- WebAuthN and Passkeys (cryptographic security primitives)
Developer-convenience features that face resistance:
- CSS Nesting (pure syntactic sugar)
- Web Components (can be polyfilled; strong React resistance)
- New DOM APIs (existing libraries already wrap them)
The distinction matters because web standards bodies have spent years creating features developers don’t want. Not because the features are bad—often they’re genuinely good. But the feedback loops make adoption mathematically improbable.
Why it matters: Browser innovation is now constrained by LLM training data patterns, not by technical standards processes. The web platform’s evolution is being shaped by AI model preferences, not developer demand.
The Three Tiers of Web Development and LLM Impact
The Head, Middle, and Long Tail
Web development divides into three distinct tiers, each affected differently by LLM defaults:
The Head: Top 1,000-1,000,000 Sites
The “head” comprises the highest-traffic, highest-revenue websites—news organizations, streaming platforms, social networks, search engines. These established sites rarely undergo technology migrations. They have stable teams, proven infrastructure, and billions in revenue linked to existing architectures.
When these organizations use LLM tools, they do so to accelerate productivity within existing stacks, not to replace frameworks. They won’t adopt new technologies unless the business case is overwhelming.
LLM Impact: Minimal. These sites create momentum for existing technology but rarely experiment with alternatives.
The Middle: Next 1,000,000-10,000,000 Sites
The “middle” comprises small-team and individual-built sites—startups, small businesses, independent projects, SaaS applications. This tier is growing rapidly and heavily uses LLM tools to accelerate development.
Critically, these developers use tools’ default outputs. When a developer prompts Claude, Copilot, or Replit to “build a web app,” they don’t specify React—they accept whatever the tool outputs. Since tools default to React, these sites deploy with React.
LLM Impact: Decisive. These are the sites building the new web, and they’re entirely shaped by tool defaults.
The Long Tail: Everyone Else
The long tail comprises non-professional developers, business users, and non-technical people using low-code/no-code tools directly within chat interfaces or visual builders. They never see code directly. Their motivation is purely functional: build a working website that solves a problem.
These users might interact with Loveable, Replit in non-code mode, or even ChatGPT directly. They’re unlikely to know or care what framework their site uses. Their tool’s capability determines what gets built.
LLM Impact: Total. These users are completely constrained by tool capabilities and defaults.
The Implication
Sites in tiers 2 and 3 are driving web growth and generating the volume of new sites (13 million+/month). These developers are entirely dependent on LLM tool defaults. They don’t use Passkeys, Web Components, CSS Nesting, or View Transitions because tools don’t know how to generate them in statistically meaningful ways.
The practical result: the web being built by AI assistance reflects only the patterns LLMs learned. New platform features don’t reach these sites unless LLMs learn to generate them, and LLMs won’t learn until patterns are widespread enough in training data.
Why it matters: The future of the web—the sites being created right now—is being shaped by AI tool defaults, not by developer choice or platform capability. This represents a fundamental shift in technological governance.
The Tool Vendor Dilemma
The Impossible Choice
Tool vendors face an impossible choice:
Option A: Support Framework Diversity
- Generate multiple frameworks (React, Vue, Svelte, etc.)
- Provide user options in tool UI
- Result: Fragmentary adoption, confused users, support burden
Option B: Default to React
- Hardcode React in system prompts
- Generate primarily React code
- Result: Happy existing developers, market alignment, simpler tool design
No vendor chooses Option A. Not because they dislike diversity, but because market pressures overwhelm principle.
Why Vendors Hardcode React
When Replit and Bolt explicitly hardcode React into their system prompts, they’re not stating a preference—they’re responding to reality. Developers expect maintainable, professional code. For the majority of developers, “maintainable code” means React. Alternative frameworks, regardless of technical merit, represent unknown territory.
From a tool vendor perspective:
- Generating React aligns with existing developer knowledge
- React has proven production patterns at scale
- React’s ecosystem provides libraries for most use cases
- Existing React codebases make code generation more useful
Tool vendors capture market share not by innovating frameworks, but by generating code that existing developers recognize and value. This economic logic forces React as the default despite any framework-agnostic design principles.
Why it matters: Even vendors theoretically capable of supporting framework diversity can’t afford to do so. Market structure enforces technological convergence through economic incentives.
What New Frameworks Actually Face
The Impossible Requirements
Launching a new web framework means solving four simultaneous problems:
Problem 1: LLM Training Data Entry (12-18 Month Delay)
New frameworks require real-world adoption before achieving statistical significance in training data. This typically requires 6+ months of actual usage, then waiting for the next LLM training cycle (annual at best). Minimum 12-18 months before the framework appears in most LLM models.
Problem 2: Tool System Prompt Integration
AI tools have hardcoded React defaults. Changing system prompts requires vendor adoption. Vendors won’t change defaults without evidence that alternatives improve user outcomes. This requires building credibility, ecosystem, and demonstrated demand.
Problem 3: Comprehensive Ecosystem Development
React’s ecosystem includes thousands of libraries and components. New frameworks typically start with dozens. Developers expect solutions for routing, state management, styling, forms, authentication, UI components, data fetching, and dozens of other concerns. Building this ecosystem requires years of community effort.
Problem 4: Developer Mindshare Conquest
Developers have mental models built around React. Learning new syntax, patterns, and paradigms requires effort. Without clear, transformative benefits, learning investment doesn’t justify switching costs. Tools don’t help—AI assistance embeds React patterns in developers’ minds.
The Catch-22
These problems create a catch-22:
To succeed, new frameworks need:
- Adoption to reach LLM training data
- But adoption is blocked by LLMs not generating the framework
- Tool defaults favor React
- But defaults won’t change without adoption
New frameworks must simultaneously solve adoption, ecosystem, developer education, and tool integration. Meanwhile, React ecosystem continues expanding (1,000+ new sites monthly), creating a moving target.
A Concrete Timeline
Frame this competition realistically:
Months 0-6: New framework launches, early adopters appear
Months 6-12: Real-world usage accumulates, community grows, first ecosystem components appear
Months 12-18: LLM training data cutoff passes; framework finally becomes statistically meaningful in training data
Months 18-24: LLM vendors create next training runs incorporating new framework
Months 24+: Tools update system prompts and start generating new framework
During this entire timeline, React ecosystem has:
- Generated 10+ million new sites
- Increased ecosystem library count significantly
- Deepened community knowledge and best practices
- Increased tool vendor investment in React
By the time competitors achieve LLM representation, they’re competing against a technology that has doubled its web presence.
Why it matters: The competitive landscape itself changes faster than new competitors can reach viability. React’s head start is measured not in years but in accumulated millions of implementations.
Recommendations for Different Stakeholders
For Framework Creators
Building new frameworks is building a product that LLMs won’t ship for 12-18 months. During that period, there’s no ecosystem, developers don’t know it, and enterprises don’t adopt it. You’re not competing with React’s technical advantages; you’re competing with statistical dominance in every LLM training dataset and tool vendor preference.
Success requires:
- Clear technical differentiation solving real, unmet needs
- Strategy for LLM training data inclusion (community size, deployment volume)
- Tool vendor partnerships for system prompt integration
- Comprehensive documentation that could reach training data
- Library ecosystem funded through community or sponsorship
- Developer education and marketing investment
Realistic outlook: dominance requires 3-5 years minimum, with sustained funding and community effort. Even then, React’s network effects may prove insurmountable.
For Platform Developers
Developer-experience features (syntactic sugar, convenience APIs) will compete against entrenched React patterns and mostly fail adoption. Focus instead on fundamental capabilities impossible to build in userland—new computing models, security paradigms, interaction patterns.
When evaluating new features, assess: does this improve the end-user experience? If a feature only makes developer code easier to write but doesn’t improve what users experience, LLM training data won’t prioritize it, and adoption will remain minimal.
Practically useful platform features:
- WebGPU (entirely new computing paradigm)
- View Transitions (native navigation improvement)
- PassKeys/WebAuthN (stronger security)
Less useful platform features:
- CSS Nesting (purely syntactic; Sass already exists)
- Web Components (strong React ecosystem resistance)
- New DOM APIs (existing libraries wrap them adequately)
The distinction matters for standards investment and realistic adoption timelines.
For Tool Vendors
If you don’t default to React, you’re limiting addressable market. Competitors satisfy current market demand. You can’t afford to sacrifice framework diversity for principle.
Strategic options:
- Specialize in non-React frameworks (small market, deep differentiation)
- Provide expert systems generating high-quality framework-agnostic code (hard problem, high value)
- Compete on code quality, not framework diversity (racing to improve outcomes)
The viable path likely involves specialization or code quality advantage, not framework neutrality.
Conclusion
The Dead Framework Theory reveals a fundamental transformation in how web technologies achieve dominance. Technological superiority is no longer sufficient. What matters instead is presence in LLM training datasets, AI tool system prompts, and developer mindshare.
React has become the web platform not through exclusive merit, but through a self-reinforcing feedback loop that grows stronger with each cycle. New frameworks face a structural problem: they must achieve adoption before LLMs learn them, but adoption is blocked by LLMs not generating them.
The long-term implications are significant:
If industry continues prioritizing developer experience and framework choice, the eventual outcome is homogenization. LLMs will build the web using React and a handful of entrenched libraries. Framework innovation will stagnate. React will become invisible infrastructure—the unchangeable platform upon which everything else builds.
But there’s an optimistic counterargument. As LLM usage intensifies, tool vendors must compete within a homogenized ecosystem. If everyone defaults to React, framework choice becomes impossible as a differentiator. Competition then shifts to code quality. Market forces could redirect focus from developer experience to user experience.
Two possible futures exist. In both, we should prepare for a world where framework choice is no longer meaningful. Either frameworks disappear into LLM-generated implementations, or framework selection becomes a backend implementation detail transparent to users.
The immediate lesson is clear: LLM training data inclusion is the new competitive battleground for web technologies. Control over what LLMs generate determines what gets built. Understanding this shift is essential for anyone building frameworks, platform features, or tools for the web’s future.
Summary
- Dead Framework Theory: Self-reinforcing feedback loops make new web frameworks “dead on arrival” against React’s dominance
- The Dual Loop: Web data → LLM training → code generation; and developer preference → tool defaults → ecosystem growth reinforce each other
- The 12-18 Month Barrier: New technologies require this period minimum to enter LLM training data, during which React ecosystem expands by 10+ million implementations
- Platform Features: Browser APIs face identical loops; only fundamental, userland-impossible features achieve adoption
- Tool Vendor Economics: Market pressures force React defaults; framework diversity is economically unviable
- Web Development Tiers: Middle and long-tail developers (building future web) are entirely shaped by LLM defaults
Recommended Hashtags
#DeadFrameworkTheory #React #LLM #WebDevelopment #AITools #Frameworks #AICoding #GenerativeAI #DeveloperExperience #WebPlatform #GoogleWeb