Why Are You Using a Framework for a Static Website?
It's not about which framework is best — it's about whether you even need one.
So here’s the story.
I used to use Next.js for everything. Blog. Portfolio. Landing page. Every time I had a website idea, my hands would just type npx create-next-app.
One day it hit me: it’s like wanting to fry a plate of rice, but what I actually did was build the kitchen first. All I needed at the time was a website with content — the rice. But I was busy setting up app-level routing, hydration, rendering strategies, build config — the kitchen. Before I’d written a single paragraph.
Sure, a kitchen has its advantages — efficient, all the tools right there. But for just one plate of fried rice, isn’t that overkill? All of that for a page that’s just text and images.
That’s when I stopped. And finally asked myself: “if all I need is the rice, why am I building the kitchen?”
The answer comes back to a basic principle: send the browser only what it actually needs. Nothing more.
Sounds simple. But look at the frameworks we use most — Next.js, Nuxt, SvelteKit — to build a blog or a landing page. These frameworks are genuinely great. But for a page that’s just text and images, many of the capabilities they offer — app-level routing, various rendering strategies, hydration, more complex data fetching patterns — often aren’t really needed. The complexity didn’t come from the website. It came from the tool I chose.
There’s a different approach. The concept is called islands architecture: most of the page stays as plain HTML. Only the parts that actually need interaction — a comment section, a search form — get JavaScript. The rest? Leave it alone. The browser doesn’t need to download JavaScript for the whole page — just the parts that are actually interactive.
I’ve tried it and, honestly, it’s pretty nice — this isn’t just theory. This blog uses that approach. I covered the details in a previous post. The impact was immediate: the technical complexity is almost gone, and my focus shifted back to writing. No more config drama or endless layers of dependencies.
But this raises a more interesting question: why do we always jump to a framework first? When the principle is that simple?
Why do I — and probably you too — automatically type npx create-... the moment I get an idea for a website?
There are a few reasons. And most of them aren’t technical.
Tutorials and bootcamps teach frameworks from day one. You type create-react-app before understanding the DOM. You learn components before you know what an HTML form is. The frontend education ecosystem has turned frameworks into the starting point, not something you use only when you actually need it.
FOMO. There’s a subtle fear: if you just use HTML, you’ll be seen as “unprofessional.” No framework = outdated. Even though nobody actually says that. It’s a voice in your own head.
AI does the same thing. In my experience, AI also tends to suggest modern frameworks as the starting point. Ask AI to build a website — its first answer is almost always npx create-next-app, npm create vite, or some other modern framework, even when you just want a one-page landing page.
This isn’t the AI’s fault. AI suggests solutions that appear most often in documentation, tutorials, open-source repositories, and the example projects in its training data. The web ecosystem today is dominated by frameworks — it makes sense that recommendations are framework-first too. But that doesn’t mean it’s always the best solution for your case.
These three reasons — tutorials, FOMO, and AI — are all valid. I’ve been there too. But there’s one question nobody seems to ask: if the project is entirely static, are these reasons still good enough?
I’m not going to say frameworks are bad. Because they’re not.
An admin dashboard full of interactive charts? A SaaS app with real-time updates? Applications that behave more like software than documents? That’s where frameworks show their strength. When your needs start including authentication, deeply interconnected state, or complex app routing — a framework becomes a sensible choice.
Frameworks also bring real advantages: consistent architectural patterns, mature library ecosystems, and a comfortable developer experience. If your project genuinely calls for those things, using a framework makes perfect sense.
But if you’re building a personal blog, a portfolio, a landing page, documentation, a company profile… the question isn’t “which framework,” it’s “do I even need one?”
And if the answer is no, that’s not bad news.
Here’s the thing: don’t start with the framework. Start with what you need. Then pick the tool.
When you stop thinking about frameworks, your focus shifts. Not because of performance or deployment — though those improve too.
Your brain has been busy: “How do I implement this?” “What components?” “Which state management?” When all you wanted to do was one thing: write content.
Let go of that mindset, and the question changes. It’s no longer “how do I build this,” but “what do I actually want to say?” That’s a huge difference. It’s not about technology. It’s about mental posture.
How? Up to you. What matters is realizing there’s a path besides npx create-next-app.
Before your hands automatically type npx create-next-app, stop for a second.
Ask yourself:
“Am I cooking rice… or building the kitchen?”