Why I’m Building My Next Side Project with Plain HTML/JS (No Framework)

Why I’m Building My Next Side Project with Plain HTML/JS (No Framework)

By Chika Eze

At some point in modern web development, we collectively agreed that everything needed a framework. React, Vue, Svelte, Next, hydration layers, state managers—stack upon stack.

But for my next side project, I’m stripping everything back to basics: plain HTML, CSS, and JavaScript.

Sometimes the fastest way forward is not adding more tools—but removing unnecessary ones.

The problem with modern frontend stacks

Frameworks solve real problems—but they also introduce hidden complexity that most side projects don’t actually need.

  • Build tools slow initial setup
  • Dependency trees increase maintenance overhead
  • State management becomes over-engineered
  • Small apps become “mini enterprise systems”

A simple idea often gets buried under architectural decisions before it even ships.

What I actually need for a side project

Not everything deserves React Server Components or global state stores.

  • Fast loading pages
  • Simple interactivity
  • Minimal hosting complexity
  • Easy debugging
Most side projects fail not because of bad ideas—but because they are overbuilt before they are validated.

What vanilla JavaScript still does better

People underestimate how powerful the browser already is.

  • No compilation step
  • No dependency installation
  • No framework learning curve
  • Direct DOM control
<button id="btn">Click me</button>

<script>
document.getElementById("btn").addEventListener("click", () => {
  alert("Simple works.");
});
</script>

This is still valid, scalable enough for many use cases, and extremely fast to ship.

The speed illusion of frameworks

Frameworks feel fast—until they don’t.

  • Initial setup is quick
  • But long-term complexity grows silently
  • Debugging becomes layered
  • Performance issues hide under abstractions
You don’t feel the cost of abstraction immediately. You feel it when things break.

When frameworks actually make sense

This is not a “frameworks are bad” argument.

They are powerful when:

  • You are building large applications
  • You need reusable component systems
  • You require advanced routing/state management
  • You work in teams at scale

But side projects rarely start there.

My current approach

For this project, I’m intentionally limiting complexity:

  • Pure HTML for structure
  • CSS for styling (no utility frameworks)
  • Vanilla JS for interactivity
  • No build tools
Constraint is not a limitation—it is a forcing function for clarity.

What I expect to gain

  • Faster iteration cycles
  • Fewer moving parts
  • Better understanding of fundamentals
  • Easier deployment

Most importantly: fewer excuses to avoid shipping.

The uncomfortable truth

A lot of developers are not slowed down by lack of tools—they are slowed down by too many of them.

Abstraction is useful. But over-abstraction is a productivity tax.

If your idea cannot survive without a complex stack, it probably isn’t validated yet.

Final insight

Going back to plain HTML and JavaScript is not regression.

It is recalibration.

Before scaling systems, you should be able to build without them.

Sometimes the most modern engineering decision is choosing not to over-engineer.