React and Vue have become the default answer to almost every web project. A landing page? Reach for React. A portfolio? Vue. A five-page marketing site? Next.js, because it's what everyone uses. The frameworks are genuinely excellent, and that reflex is understandable. But it's still a reflex, and for simple, non-data-driven websites it usually costs more than it returns.
Here's the honest breakdown: what frameworks are actually built for, where they start to work against a simple site, and what to reach for instead.
Start With the Job, Not the Tool
Every web project sits somewhere on a spectrum. On one end are simple content sites: mostly static pages of text and images, where the "interaction" is a navigation click. On the other end are applications: dashboards, feeds, editors, anything where data changes in many places at once and the interface has to keep up.
React and Vue were built for the second end of that spectrum. So the useful question isn't "which framework?" It's "is this a website or an application?" If it's a website, most of the framework never turns on, but you still pay for it.
What Frontend Frameworks Are Actually Built For
Frameworks solve application problems: component reuse across a large UI, reactive state, client-side routing, and keeping many parts of an interface in sync with changing data. On a chat app, an analytics dashboard, or a tool with heavy interactivity, that machinery is worth every kilobyte. The mistake is treating a tool built for application complexity as a default for documents. A blog post doesn't have state. It has words.
Where the Framework Starts to Cost You
Once the framework is in place, four costs show up on every simple project. None of them are fatal on their own, but they compound.
Overhead: You End Up Building the App Before the Website
A framework isn't a single file you drop in. It's a build tool, a bundler, a router, a state strategy, and a folder structure to hold them all. Before you write the first line of actual content, you've configured a pipeline. For an application, that setup earns its keep. For a simple site with a handful of static pages, you're doing application work to publish documents, and it unnecessarily complicates the whole process.
Performance: Shipping a Runtime to Display Static Text
A static page of HTML and CSS can paint as soon as it arrives. A framework page usually has to arrive, load a JavaScript runtime, and then render. That extra work is invisible on a fast machine and very visible on an older phone or a slow connection. For a simple website, the bundle is larger than the content it renders, and the loading time grows in the exact conditions where attention is hardest to keep.
The Learning Curve Is a Real Cost
React and Vue carry a learning curve: components, props, hooks or reactivity, lifecycle, tooling. That investment pays off when you'll use the framework across many projects and much of your career. If you're building one brochure site and moving on, the time you spend learning the framework is time you didn't spend on the site itself. Learning a tool you'll rarely use isn't a bad thing. It's just not an efficient use of your resources.
Maintenance Doesn't Stop at Launch
Every dependency is a small ongoing tax. With a framework, you maintain two codebases: the code you wrote, and the framework plus its ecosystem, which keeps moving. Security patches, major versions, breaking changes, and migrations arrive on someone else's schedule. On a complex app, that maintenance is part of the deal. On a simple site that hasn't changed in a year, it's overhead for functionality you never used.
A Lighter Path for Simple Websites
For a site that mainly publishes content, three options do the job with far less machinery.
Plain HTML, CSS, and JavaScript
For genuinely simple websites, nothing beats the simplicity and performance of plain HTML, CSS, and JavaScript. You have full control over every aspect of the page, there's no build step, and the result loads instantly because there's no runtime to wait on. Modern CSS now handles layouts and interactions that used to require a framework, so the gap keeps narrowing.
Static Site Generators
Static site generators (SSGs) like Eleventy, Hugo, and Astro are built for exactly this kind of site. You write content in Markdown, they generate plain HTML at build time, and you deploy static files anywhere. You get the speed and simplicity of hand-written HTML without repeating yourself across every page, plus fast loads and easy hosting without server-side processing.
A Content Management System
If you or a client need a friendly interface for editing content, a CMS like WordPress or Ghost might fit better. These platforms handle the editing experience and the backend infrastructure, which makes them a strong choice for blogs and content-heavy sites. You trade some control for convenience, and for a lot of teams that's the right trade.
When a Framework Is the Right Call
This isn't an argument against React or Vue. It's an argument for matching the tool to the job. Reach for a framework when:
- The interface is stateful. Data changes in many places and the UI has to stay in sync.
- Users interact heavily. Real-time updates, complex forms, drag-and-drop, live collaboration.
- The app is large and long-lived. You need component reuse, routing, and a team working in parallel.
- Offline or app-like behavior matters. You need a service worker, local data, or installability.
If most of that sounds like your project, the framework will save you more than it costs. If none of it does, it's likely furniture you'll maintain but never sit on.
Pick the Tool That Matches the Job
The best stack for a simple website is usually the smallest one that gets the job done: plain HTML, a static site generator, or an established CMS. React and Vue are powerful tools for complex, data-driven web applications, and using them for simple sites often introduces complexity, overhead, and maintenance that the project never needed.
None of this is about avoiding frameworks. It's about refusing to let a default replace a decision. Ask what the project actually requires, then choose the tool that answers it, even when that tool is plain HTML. Simpler is not less professional. It's just the right size.
