Frontend frameworks solved a coordination problem more than a technical one. React, Vue, and Angular became dominant not because writing vanilla JavaScript was technically impossible, but because writing it consistently, across a team, across months of iteration, was genuinely hard. The framework gave everyone a shared vocabulary. State goes here. Side effects go there. Components look like this. When a new developer joined, they had a map.
That context matters a lot when evaluating the argument in this piece from dlants.me, which claims that with AI assistance, you barely need a frontend framework at all. The author built a tool called vamp, a Neovim plugin with non-trivial UI, and found that leaning on an LLM to generate vanilla JavaScript worked well enough that the framework question almost didn’t arise. The conclusion they reach is that AI has quietly changed the cost-benefit analysis.
The argument is worth taking seriously. But it requires being precise about which part of the framework bargain AI actually replaces.
Why Frameworks Won
The jQuery era collapsed under its own weight. By 2012, a moderately complex single-page application built with jQuery had become a spaghetti of $(document).ready callbacks, global state, and ad-hoc DOM mutations that no consistent pattern could tame. Angular 1 and then React arrived with a clear offer: give up direct DOM manipulation, accept a rendering model, and get predictability in return.
What React specifically sold was a model where UI is a function of state. You stop thinking about mutations and start thinking about renders. The virtual DOM diffing was an implementation detail; the conceptual shift was the product. Once that model spread, it became a hiring filter, a documentation assumption, and a tooling target. The ecosystem locked in around it.
The cost was real: a non-trivial build pipeline, a learning curve, an abstraction layer between developer intent and browser behavior, and an update treadmill that still hasn’t fully slowed. For a small tool or a personal project, that cost often exceeded the benefit. The framework was optimized for teams maintaining large applications over long timelines.
What AI Changes
The honest answer is that AI substantially lowers the cost of writing correct, idiomatic vanilla JavaScript. Tasks that were tedious to do by hand, like wiring up event delegation across a dynamic list, managing a small piece of local state without a library, or keeping DOM structure and data in sync across a few interactions, are now the kind of thing you can prompt your way through in seconds.
Consider what a simple reactive counter looks like without a framework:
let count = 0;
const el = document.getElementById('counter');
function render() {
el.textContent = count;
}
document.getElementById('increment').addEventListener('click', () => {
count++;
render();
});
render();That’s trivial. The question was never whether this was possible without React. The question was what happens when you have fifty pieces of state like this, spread across twenty files, touched by six developers over eighteen months. Frameworks answered that question by providing structure that humans could follow reliably.
AI doesn’t change the eighteen-month problem in large teams. It does change the calculus for the single developer building a tool for themselves, or a small prototype, or a Neovim plugin. For those use cases, the LLM is essentially serving as the framework: it enforces its own implicit conventions through the code it generates, it handles the repetitive structure, and it keeps things consistent enough for one person to follow.
This is not a new insight in spirit. The htmx project has been making a related argument since 2020: that hypermedia, handled closer to the HTML layer, is sufficient for most web applications and that the complexity of heavy JavaScript frameworks is often self-imposed. Alpine.js took a similar position from the opposite direction, adding just enough reactivity to HTML attributes to handle common UI patterns without a build step. These projects were right about the problem. AI is a different kind of answer to the same diagnosis.
What Doesn’t Change
Frameworks provide things that LLMs genuinely do not substitute for, even in 2026.
The first is type safety across a large codebase. TypeScript with React gives you component prop types, hook return types, and event handler signatures that a compiler can check. When you refactor a component’s interface, the type errors tell you every callsite that broke. Vanilla JavaScript with AI-generated code gives you neither the compiler checks nor the consistent typing discipline. You can add TypeScript to vanilla JS, but you lose the framework’s typed ecosystem.
The second is routing, server integration, and the full application model. Next.js, Nuxt, and SvelteKit are not just reactive UI layers; they are full application frameworks with file-based routing, server-side rendering, API routes, and build optimization. Replacing that with vanilla JavaScript and an LLM does not obviously scale, even for solo developers, once the application crosses a certain surface area.
The third is long-term maintainability by the LLM itself. One underappreciated point: LLMs are trained heavily on framework code. React patterns, hooks, component composition, and the like appear constantly in training data. Vanilla JavaScript patterns for complex state management appear much less frequently. This means the LLM’s suggestions are often more reliable, more idiomatic, and more consistent when working within a known framework than when improvising bespoke state management. The framework is, in a real sense, part of the LLM’s working vocabulary.
The Actual Sweet Spot
The argument that AI makes frameworks optional holds up well for a specific class of projects: personal tools, plugins, small interactive pages, prototypes, and standalone utilities. Exactly the kind of thing the vamp author was building. For these, the overhead of a framework, the build tooling, the dependency tree, the mental model, was always a poor fit. AI makes the alternative easier to execute.
For production applications with teams, frameworks are not going anywhere. The coordination problem they solve is human, not computational, and AI does not replace human coordination. A shared framework means that when a developer reads a PR, they already know where to look. They know what a useEffect dependency array means. They know where side effects should live. That shared knowledge is load-bearing infrastructure for how teams ship software.
What may actually shift is the threshold at which a project graduates into needing a framework. A year ago, a moderately complex single-page tool might have defaulted to React out of habit and tooling familiarity. With AI assistance, that same project might stay vanilla longer, or move to something lighter like Lit or Preact, before the complexity truly demands more. That’s a meaningful change in practice even if it’s not the revolution the headline implies.
There’s also a version of this argument that lands differently for backend-driven applications. Server-rendered HTML with minimal JavaScript has never needed React. The case for Hotwire, htmx, or a simple template-rendered page was always strong for content sites and form-heavy apps. AI hasn’t changed that calculus so much as it has added another path to the same destination: less JavaScript, closer to the HTML.
A More Grounded Conclusion
The point that resonates in the dlants.me piece is not that frameworks are obsolete, but that the default to frameworks was often unjustified. Developers reached for React because the ecosystem assumed it, because job postings demanded it, because tutorials started there. The friction of not using it felt higher than the friction of using it.
AI lowers the friction of not using it. That’s a real shift. Vanilla JavaScript with an LLM in the loop is now a genuinely competitive option for small and medium projects in a way that it was not two years ago. The projects that actually needed a framework still need one. The projects that were using a framework out of inertia now have a viable off-ramp.
That’s a more modest claim than the headline suggests, but it’s the one that holds up under pressure.