Developers are ditching frameworks. Here's what that means for the web.

The shift: Frameworks are losing their grip

For the best part of a decade, starting a new web project meant picking a framework before anything else. React, Vue, Angular, Svelte - the options changed with the years, but the assumption held. A framework was the default. The only real debate was which one.

That assumption is breaking down. Research puts roughly 40% of new web projects in 2026 skipping heavy frameworks entirely, reaching for vanilla JavaScript and native browser APIs instead. Shopify rebuilt its entire Polaris design system - used across Admin, Checkout, and Customer Accounts - using Web Components, no framework in sight. Google's Material Design team made the same call. These aren't indie projects made by developers with a point to prove. They're production systems serving millions of users every day.

The question most teams are asking in 2026 isn't "which framework?" It's "do we actually need one here?"

The reason: The browser finally caught up

JavaScript frameworks solved real problems when they arrived. In 2013, the native browser environment was inconsistent, limited, and painful to work with at any scale. React gave developers a component model when the platform offered none. Angular gave structure. Vue gave a gentler starting point. All of them fixed something real.

But the web moved on. The platform kept adding the exact features frameworks were built to provide.

Fetch replaced XMLHttpRequest. ES Modules gave JavaScript a proper import system. CSS Grid and Flexbox killed the need for layout libraries. Web Components - despite years of scepticism from all sides - now work consistently across every major browser.

The practical result: a large chunk of what developers needed React for in 2018, they can now do with a few dozen lines of plain JavaScript. No build step, no dependency tree, no bundler configuration to unpick at 11pm. And none of the framework upgrade cycle that turns a quiet Tuesday into a breaking change.

The maintenance cost is where this really bites. Frameworks release breaking changes. Dependencies go stale. Major versions drop support for older patterns. For a site meant to run for three or four years, a framework that moves fast is a liability as much as it is a feature.

The trade-off: This isn't the end of React

React runs on around 45% of websites that use a JavaScript framework, and that figure isn't about to collapse. Complex applications - design tools, dashboards, anything with deeply interactive and stateful UI - still benefit from what a mature framework provides. Managing state across dozens of interdependent components is genuinely harder without one, and anyone who says otherwise hasn't tried it at scale.

The shift is in the default assumption, not the technology. The developers leading this movement don't argue that frameworks are always wrong. They argue that frameworks get chosen by habit rather than necessity - particularly for the kinds of sites that make up most of the web. Content-driven, mostly static, with a handful of interactive elements. A marketing site, a product page, a brochure, a news-driven platform. Vanilla JavaScript handles all of that comfortably: less code, fewer dependencies, no runtime overhead between the browser and the person using the page.

AI coding tools have pushed the trend further. 68% of developers now use AI to generate code during development. One of a framework's traditional arguments was that it gave teams shared patterns to follow. When AI generates clean, idiomatic vanilla JavaScript as fast as it generates React components, that argument loses most of its force.

The content layer: Where headless CMS fits in

Go lighter on the front-end and you still need somewhere to put the content. This is where we spend a lot of our time at Lavine Web & AI Solutions - and where the choice of CMS starts to matter more than people expect.

A traditional CMS like WordPress is opinionated about how content reaches users. It renders the pages, controls the templates, determines the output. When the front-end is a lean JavaScript application, that coupling is the wrong fit. You want a content layer that holds the data and hands it over via a clean API, without deciding how anything gets displayed.

Demand for exactly that is growing fast. The headless CMS market is forecast to reach $4.59 billion by 2033, up from $860 million in 2024 - a 22% compound annual growth rate driven largely by developers rejecting the monolithic CMS model.

For most of the last decade, WordPress was our default for anything that needed a CMS. It works, clients know it, and the ecosystem around it is vast. New projects are a different story. We have used PayloadCMS on a couple of builds now, and all new work is moving onto it. It comes with a sleek, uncluttered admin panel and a configurable dashboard, completely uncoupled from the website frontend and extendable with custom plugins - which means editors get a clean, focused interface and developers can shape the system around the project rather than the other way around.

Figma bought the Payload team in June 2025. Figma - used by the majority of product and design teams worldwide - decided it needed serious content infrastructure at the heart of its product and went out and bought it. The project has stayed open source, the team has stayed focused on the framework, and the numbers have kept climbing: 5 million npm downloads, 40,000 GitHub stars, weekly releases with no sign of letting up.

Pairing a lean JavaScript front-end with a code-first headless CMS produces a clean, coherent architecture. The front-end does what it needs to do. The content layer stays developer-friendly and easy to extend. Nothing in the stack is doing nothing.

The bottom line: What this means if you're building something new

Lighter stacks cost less to run and less to maintain. A codebase without a tight framework dependency doesn't create a crisis when the framework team changes direction or drops support for something your site relies on.

Performance carries real commercial weight now. Google's Core Web Vitals directly affect search rankings. Every 100 milliseconds of load time has a measurable effect on bounce rate and conversion. Cutting framework overhead means faster pages - better rankings, lower bounce rates, and users who stick around long enough to do something. For most SMEs, the cost of a heavy framework is invisible at launch and becomes very visible twelve months later when the first major update drops and something breaks.

The developers driving this aren't cutting corners. They are making considered calls about where complexity pays for itself - and removing it where it doesn't.

Steve Lavine is a full-stack developer and founder of Lavine Web & AI Solutions, working with SMEs and startups across the UK. lavine.dev