I Built a Framework-Free Blog and Stopped Apologizing for It

Three months ago, I was sitting in a client meeting in Islamabad when someone asked what stack I'd recommend for their new content platform. My instinct was to say Next.js. Then I paused and thought about their actual problem: they needed to publish articles, not build a real-time dashboard. That moment made me revisit something I'd been avoiding, why do we default to frameworks for problems that don't need them?

I've spent the last five years building with React, Vue, and everything in between. They're powerful tools. But I started noticing something frustrating: I was shipping 200KB of JavaScript to render text that could have been pure HTML. The gap between what my projects actually needed and what I was deploying kept bothering me. When I read about someone shipping a 50+ article blog with zero frameworks, I didn't dismiss it as "too simple." I got curious about whether I was overcomplicating my own work.

The Real Problem With Default Thinking

Here's what I realized: I was reaching for frameworks because they're familiar, not because blogs need them. A blog has exactly one job, serve content fast. It doesn't need state management, it doesn't need client-side routing, it doesn't need component re-rendering. Every framework feature I added was solving a problem that didn't exist on a content site.

The author here nailed something I've been feeling for a while. Frameworks solve scaling problems. They organize large teams. They handle complexity. But if your site is mostly static content, that complexity becomes overhead. I've started to think of it this way: frameworks are like hiring a project manager for a two-person team. Powerful if you need it, wasteful if you don't.

Building Something Actually Minimal

What appealed to me most was the architecture philosophy. Instead of forcing Markdown through a framework's opinionated pipeline, this approach treats the build step as a simple prerendering process. Write Markdown with YAML front matter, run a Node script, get HTML. No magic, no hidden dependencies, no waiting for Webpack to do its thing.

I started sketching this out for my own site. The build would be a series of focused scripts, one to parse Markdown, one to generate feeds, one to build sitemaps. Each script is idempotent, meaning running it twice produces identical results. That alone eliminates a whole class of bugs I've chased before.

The bilingual feature particularly caught my attention. Instead of pulling in a heavy i18n library, they just used a JavaScript object mapping keys to translations. It's elegant. I've wasted hours configuring i18n frameworks for projects that only needed five or six translated strings. This approach scales from five strings to five hundred without changing philosophy.

My Take: The Trade-Off Isn't About Speed Anymore

I agree completely that zero frameworks means zero dependency updates. That's real. I've had production incidents because a minor patch in some transitive dependency broke my build. No node_modules means no vulnerability alerts at 2 AM. But I want to be honest, speed isn't actually the differentiator here anymore. Modern frameworks are fast enough. The real win is simplicity and control.

Where I'd push back slightly: this works brilliantly for content sites, but the moment you need client-side interactivity beyond "toggle dark mode," you're building your own framework. And poorly. I've seen "simple vanilla JavaScript" projects balloon into unmaintainable spaghetti because they outgrew their initial scope. The question isn't whether frameworks are unnecessary, it's whether you actually know your problem well enough to reject one.

For a blog that's genuinely just articles? Yes, go framework-free. For anything that might accumulate features over time? Be skeptical of that answer.

A Practical Pattern

Here's a build script structure that actually works:

// build-articles.cjs
const fs = require('fs');
const marked = require('marked');
const matter = require('gray-matter');

function buildArticles() {
 const articlesDir = './src/articles';
 const outputDir = './dist/posts';
 
 fs.readdirSync(articlesDir).forEach(file => {
 if (!file.endsWith('.md')) return;
 
 const content = fs.readFileSync(`${articlesDir}/${file}`, 'utf-8');
 const { data, content: body } = matter(content);
 const html = marked.parse(body);
 
 const page = generatePage(data, html);
 fs.writeFileSync(`${outputDir}/${data.slug}.html`, page);
 });
}

buildArticles();

This is the entire philosophy: read files, transform them, write files. No watchers, no bundlers, no magic.

What I'm Actually Doing Next

I'm not going to rebuild my client work to be framework-free. That would be dogmatic. But my personal blog? I'm testing this approach on a small section first. One category of posts, built with the pattern above, deployed to see how it actually feels to work with.

Here's what I want to know from you: if you're maintaining a content site right now, what makes you reach for a framework? Is it genuinely the problem, or is it just the gravitational pull of the ecosystem?

Source: This post was inspired by "How I Built a Static Blog with 50+ Articles and Zero Frameworks: Pure HTML, CSS, and JavaScript" by Dev.to. Read the original article