Web Directions Year round learning for product, design and engineering professionals

Front-end development has become extraordinarily complex over the past fifteen years. What was for nearly the first two decades been the relatively simple direct manipulation of the Document Object Model (DOM) using HTML, CSS, and JavaScript has evolved into an intricate ecosystem of frameworks, build tools, state management libraries, and abstractions upon abstractions. React, Angular, Vue, Next.js and their surrounding ecosystems have become the default approach to modern web application development.

But we should take seriously the idea that this entire stack may be in the process of becoming increasingly obsolete—because the core problem it was designed to solve is disappearing.

Developer Experience

So why did we see the rise of AngularJS, React, and other frameworks as the foundation for developing for the web? It was sold as being fundamentally about developer experience. Working directly with the DOM was painful, especially a decade or more ago when browser inconsistencies were more pronounced and the browser’s native capabilities more limited. Frameworks and libraries, like Angular and React, emerged to smooth out these rough edges, provide higher-level abstractions, and make developing complex interactive applications more manageable.

This approach enabled (and was predicated on) the single-page application (SPA) architecture that has become the dominant pattern for modern web applications, promising rich, native-like user experiences in the browser, in response to “The web is dead, native apps are the future” (thinking of the early 2010s).

But these approaches came with significant and now increasingly well-understood costs. Performance overhead has become a well-documented challenge. Applications built this way require more client-side processing, more network round-trips, and more complex runtime behavior—waste that has been unnecessary and maladaptive for years, though we might only recently have started really paying attention.

The complexity explosion went beyond just performance. Ask a junior developer to set up a new project from scratch, and watch them struggle with the maze of configuration files, build tools, and dependencies that are supposed to “make it easier.” Onboarding is a significant and probably undocumented cost for teams when hiring new developers. When spinning up a new project how much scaffolding do you need before you can write your first line of actual application code? The answer has grown significantly over the years.

We’ve created an ever-increasingly complex set of dependencies, spawning entire sub-specializations dedicated to managing nothing but the dependencies of an application. How many developers are still using Babel because they think they have to, when it’s actually just passing code through unchanged because they’re targeting modern browsers?

Inception-like, we’ve built elaborate solutions to manage the complexity that our solutions to the original complexity introduced. Seeking to improve developer experience, we have ironically simultaneously eroded it. The promise of better DX has failed to materialize—instead, we’ve created a tower of abstractions where productivity, if properly measured, is often lower than if we were writing Django templates in Notepad++.

A Full Stack of Leaky Abstractions

This failure becomes clearer when you examine the layers we’ve accumulated. As Joel Spolsky observed a generation ago, all abstractions are leaky. And in our current front-end stack, we have layer upon layer of them:

• The DOM and web APIs at the foundation
• HTML, CSS, and JavaScript as the native web technologies
• Libraries and frameworks–like React and Angular
• Framework-specific abstractions (React components, Angular services, Vue directives)
• State management libraries (Redux, MobX, Vuex)—which inadvertently highlight how weak the reactive frameworks themselves are at the very “state management” they are supposed to solve
• UI component libraries built on framework abstractions
• Build tools to compile, bundle, and optimize
• Meta-frameworks to manage the frameworks managing the web platform

Each layer may have been added for sensible reasons at the time. But each also introduced its own complexities, dependencies, and maintenance overhead. The abstractions leak, the problems compound, and developers increasingly don’t know what problem each abstraction was originally solving—especially as the underlying technology has evolved and improved.

Consider a simple example: view transitions, which have been widely available for over a year on the web platform, and which can safely be used with progressive enhancement. In React, view transitions still have only experimental support. It may be 18 months or perhaps even years between when this technology could be reliably used in modern browsers and when developers who rely on React get access to it. This delay feels eerily reminiscent of when jQuery finally incorporated native DOM selection—long after querySelector made its selector engine obsolete.

AI as the New Developer Experience

Large language models are developer experience now.

The entire justification for this complex stack was to make development more manageable for human developers. But when AI is generating some or even the majority of your code, those human convenience factors become not just irrelevant, they become counterproductive.

An AI doesn’t struggle with DOM manipulation APIs or complex JavaScript event handling. It doesn’t get confused by browser inconsistencies or need higher-level abstractions to manage complexity. AI can target the DOM directly using standard HTML, CSS, and JavaScript, generating precisely the code needed for specific functionality without framework overhead.

However, there’s a crucial caveat that some reviewers of this article have pointed out: AI coding agents can struggle in “large sandboxes.” The combination of HTML, CSS, and all browser APIs represents a vast playground. This suggests that some form of guidance or boundaries—whether frameworks or an alternative concept—might remain useful for focusing agentic interactions. The question becomes: what’s the minimal scaffolding needed to guide AI effectively without the overhead we’ve accumulated for human convenience?

Currently, tools like v0, Lovable, and other AI code generators ironically default to, even trumpet the fact they generate, React-based output—either as a deliberate product decision or because their training data consists predominantly of React examples. We’re forcing AI generation tools to adopt human systems of abstraction, perhaps because it’s easier for developers to integrate the output into existing codebases where this whole artifice already exists. Perhaps because we are so constrained in our thinking about what front-end engineering could be.

OpenAI’s own recent Frontend coding with GPT-5 tellingly advises using Next.js, React, Tailwind CSS, and various UI libraries. But there’s no technical reason these systems couldn’t generate vanilla web platform code that’s more performant and has fewer dependencies. The limitation is our own expectations and assumptions about what “proper” web development looks like.

The Platform Has Evolved Too

This shift becomes even more compelling when you consider how much the web platform itself has evolved and improved over the last 15 years, an evolution that is only accelerating.

CSS Grid and Flexbox eliminated the layout challenges that drove the development of frameworks like Bootstrap. Anchor positioning adds new sophistication still. Web Components provide native component abstractions. Service Workers and IndexedDB enable sophisticated offline experiences. The Intersection Observer API, ResizeObserver, and other modern APIs handle complex interaction patterns directly.

Features like View Transitions, Speculation Rules, and emerging local-first architectures (including SQLite in the browser) point toward an increasingly capable native platform. These capabilities arrive in browsers first, then get wrapped into frameworks months or years later—often with additional overhead and complexity that serves no purpose for AI-generated code.

The Transition Challenge

This doesn’t mean abandoning everything overnight. As reviewers of this article observed, the transition will be lumpy and challenging. Different parts of the stack will be abandoned at different rates—some might die overnight while others persist for years. This creates significant planning challenges:

For CTOs and engineering leaders: How do you plan when fundamental assumptions about stack stability are eroding? Which teams work on what? What needs ongoing support, and what should be abandoned as legacy? How do you manage security updates in libraries that maintainers might abandon?

For individual developers: The good news is you too have options:

• Invest in platform knowledge. Understanding the capabilities that frameworks abstract away becomes more valuable, not less. These are the building blocks AI will use. Your role increasingly involves architecting solutions and specifying approaches that models will implement.
• Experiment with AI development workflows. Whether through Copilot-style assistance, conversational development, or with tools like Claude Code and Codex that integrate into modern development processes–these capabilities are becoming essential.
• Work with different models. Models have their own specific strengths, weaknesses, and quirks that take time to understand. So don’t simply work with and rely on the same model.
• Guide AI with specificity. Rather than letting models default to framework-heavy solutions (their training data average), be explicit about the technology stack you want them to use. “Use CSS Grid for layout” or “Use the Intersection Observer API for lazy loading” produces better results than letting AI reach for its defaults. Develop your own specifications that provide the overarching architectural context for models to use.
• Consider the full cost of framework complexity. Performance, dependencies, build processes, upgrade cycles—all become less necessary overhead for AI-generated code. The complexity that supposedly helps humans actually creates more places for AI errors.

Gradually…

While prediction is hard—particularly about the future—the signals suggest this transition may happen faster than expected. We’ve seen this pattern before: jQuery became a legacy technology once browsers became consistent. Polyfills disappear as native support for their features improve, and become ubiquitous. JavaScript animation libraries gave way to CSS animations and transitions.

As an example that has been widely cited is Amazon touting the potential of using LLMs to transition legacy Java codebases:

“The average time to upgrade an application to Java 17 plummeted from what’s typically 50 developer-days to just a few hours. We estimate this has saved us the equivalent of 4,500 developer-years of work.” — Andy Jassy, CEO, Amazon

Similar approaches may help migrate framework-heavy applications to vanilla JavaScript and modern web APIs. Once tools can reliably perform these large refactoring jobs, the dam may burst—starting slowly, then accelerating rapidly.

Several reviewers noted we’re already further along this path than it appears. Observations about the complexity and cost of ‘modern’ framework-based front-end development practises predate the rise of LLM-based code development tools; artificial intelligence simply provides an accelerated path to minimising that complexity.

We’ve seen this scene before in web development. Technologies like Gatsby, CoffeeScript, Grunt can vanish seemingly overnight. Which parts of our existing front-end development stack will be next?

Then suddenly

The “collapse” of the modern front-end framework stack won’t be a failure—it will be a simplification. When the challenges that motivated the fifteen years of increasing complexity no longer exist, simpler solutions become not just attractive but inevitable.

The current front-end stack evolved and became increasingly complex and complicated to solve human challenges when developing for the web platform. AI changes the nature of those challenges fundamentally.

As Rich Hickey observed in his justifiably lauded presentation, “Simple made easy“–we should aim for simplicity because simplicity is a prerequisite for reliability.

The simpler system that emerges might look surprisingly familiar: HTML, CSS, and JavaScript working directly with the DOM, generating fast, lightweight applications that take full advantage of modern web platform capabilities. With some far less complex structure and scaffolding to guide AI within reasonable boundaries, but nothing like the towering complexity we’ve accumulated.

We’re removing the need for developers to integrate AI outputs into existing codebases filled with human-centric abstractions. Instead, we’re inverting the direction—letting AI generate clean, direct code from the start, guided by knowledgeable developers.

Thanks

A huge thanks to A.J. Fisher, Damon Oehlman, and Alex Russell for reviewing and critiquing early drafts of this piece.