Dead Framework Theory

Impact of LLMs on Framework Choice

• Core claim debated: LLMs defaulting to React (because of its dominance in training data and tools) could lock in React and make new frameworks harder to adopt (“statistical dominance” over technical merit).
• Supporters see a snowball effect: more React from LLMs → more React in the wild → more React in future training data → further reinforcement.
• Skeptics argue LLMs already work fine with Vue, Svelte, HTMX, Elm, custom DSLs, and obscure frameworks when given examples or repo context, so bias is real but not decisive.
• Some expect future frameworks/languages to be designed explicitly for agentic tools (stronger typing, less ambiguity), potentially displacing today’s human-optimized stacks.

React, Build Steps, and Alternatives

• One line of criticism: React’s near-mandatory compilation/bundling (e.g., JSX, TS) is an unnecessary friction, especially when modern browsers support ES modules and simple vanilla JS/Web Components can avoid build steps.
• Counterpoint: serious projects already have build steps (minification, linting, typechecking, asset fingerprinting); modern bundlers with hot reload make React’s compile loop almost instantaneous, especially compared to older compiled languages.
• Some argue: if you’re going to have a build step anyway, React’s ergonomics and abstractions are worth it; others counter that React’s abstraction is leaky and often leads to “spaghetti” apps where business logic is hard to locate.
• Web Components, HTMX, Elm, Alpine, Svelte, Vue, and even custom micro-frameworks are cited as viable, often simpler or more introspectable options.

JS Ecosystem Churn, Stability, and Performance

• Several welcome the idea that LLM-driven standardization might finally dampen endless JS framework churn; others say the ecosystem has already stabilized post-React hooks.
• Complaints persist about breaking changes, router churn, and upgrade hell, especially around React and its ecosystem.
• There’s a heated side debate on performance: some blame modern JS frameworks (notably React) for sluggish apps like Gmail; others insist performance problems are more about product decisions and bloat than any particular framework.

JSX, Standards, and Compatibility

• Idea floated: using JSX as a shared view DSL could be a “loophole” for new frameworks—LLMs already emit JSX; you just swap in your own renderer.
• Pushback: JSX has no single, standardized semantics; different frameworks transform it very differently, making standardization unlikely.