In short
Most content-driven sites (marketing pages, blogs, documentation) default to a JavaScript framework out of habit rather than need — plain HTML/CSS/JS often ships faster, loads faster, and has fewer moving parts to maintain, and a framework earns its cost only when genuine client-side interactivity or complex state actually exists.
The default that stopped being questioned
At some point, reaching for a JavaScript framework became the unquestioned starting point for building any website, regardless of what the site actually needed to do. A marketing homepage, a documentation site, a blog — none of these inherently need client-side routing, complex state management, or a virtual DOM. They need content, delivered fast, and styled well.
What a framework is actually solving
Frameworks like React, Vue, and their peers solve real problems: managing complex, interdependent UI state, coordinating updates across a large component tree, building genuinely interactive applications. If your site has that kind of problem — a dashboard with live-updating data, a complex multi-step interactive tool — a framework is the right call. Most content-driven sites don't have that problem; they have a content-delivery problem, which is a different problem with a different best tool.
The cost that's easy to overlook
A framework adds a build step, a dependency tree that needs updating and can introduce vulnerabilities, and — critically — a JavaScript bundle that has to download, parse, and execute before a visitor sees meaningful content, even on a page that's fundamentally just text and images. For a content site, this cost buys nothing the visitor actually benefits from; it's pure overhead relative to the job the page is doing.
What you get back by not using one
A static HTML/CSS/vanilla-JS site loads faster (nothing to hydrate), has no build step to fail, no framework version to eventually upgrade under deadline pressure, and a dramatically smaller attack surface and dependency count to maintain over the site's lifetime. For a marketing or content site, none of the framework's benefits apply, and all of these costs are avoided.
This isn't an argument against frameworks generally
A product with real interactive complexity — a design tool, a dashboard, a multi-step configurator — genuinely benefits from a framework's state management and component model. The point isn't that frameworks are bad; it's that reaching for one by default, for every project regardless of its actual needs, optimizes for developer habit over the site's actual requirements and the visitor's actual experience.
A better question to ask at the start
Instead of "which framework should we use," ask "does this project have a problem a framework solves." If the honest answer is "it's mostly content, with maybe a little interactivity," a zero-build static approach is very likely to serve both the team and the visitor better than defaulting to a framework nobody stopped to question.
More from our insights: Modern Front-End Architecture: A Complete Guide.
Common questions
Is this an argument against using frameworks at all?
No — frameworks are the right tool for genuinely interactive, stateful applications. The argument is against defaulting to one for content-driven sites that don't have that kind of problem.
Doesn't a framework make a site easier to maintain long-term?
For complex interactive applications, often yes. For a content site, a framework typically adds more maintenance burden — dependency updates, build tooling, version upgrades — than it removes.
What's a good signal that a project actually needs a framework?
Genuine, non-trivial client-side state that's hard to manage with vanilla JavaScript — complex interdependent UI, a large component tree with shared state — rather than a site that's primarily delivering content.