Can CeylanVienna-based, globally curious.
Learn/Frontend

The no-build frontend: when you don't need React

Most internal tools and personal dashboards don't need a JavaScript framework. Here's the case for plain HTML and when the complexity earns its keep.

2026-04-13·2 min read·beginner

Every time I start a new project, someone asks: what framework are you using?

Sometimes the honest answer is: none. Just an HTML file.

What a no-build frontend is

A no-build frontend is a web interface written in plain HTML and JavaScript, with libraries loaded from a CDN via <script> tags. No bundler (Webpack, Vite), no transpiler (Babel), no package manager for the frontend.

<script src="https://cdn.jsdelivr.net/npm/chart.js"></script>

You edit the file. You refresh the browser. You see the change. That's the entire workflow.

Why this exists

Modern frontend toolchains — React, Next.js, Vue — are genuinely powerful. They solve real problems at scale: component reuse, type safety, shared state, server-side rendering.

But they add overhead. npm install pulls in hundreds of packages. Build times add friction. Deployments need a pipeline. For a personal dashboard or an internal tool, that overhead isn't justified by the complexity of the UI.

The no-build approach trades framework power for zero friction. It's the right tool for a specific set of problems.

When to use it

  • Personal tools and dashboards — you're the only user, UI is simple
  • Internal tools — limited audience, no SEO requirements
  • MVPs — validate the idea before investing in infrastructure
  • When one developer does everything — no need to coordinate frontend conventions across a team

I used this approach for a personal data monitoring dashboard — a single HTML file served directly by the Python backend, with a charting library loaded from CDN. No npm, no build step, no deployment pipeline for the frontend. For a solo internal tool, it was the right call.

When to graduate to a framework

The no-build approach starts to hurt when:

  • You need 3+ distinct "pages" with routing between them
  • Multiple developers work on the frontend simultaneously — no module system makes coordination hard
  • You need TypeScript for type safety on complex data structures
  • You're building a public product that needs SEO (server-side rendering matters)
  • Component reuse becomes painful — you're copy-pasting the same HTML in multiple places

The inflection point is usually when you catch yourself manually managing state across a growing number of UI elements. That's when Vue via CDN (still no build step) or migrating to Vite earns its complexity.

The professional framing

This pattern is sometimes called a zero-toolchain frontend or vanilla JS SPA (Single-Page Application). The underlying principle is choosing the right level of complexity for the problem — one of the most underrated skills in software.

Over-engineering is a real cost. An internal monitoring dashboard doesn't need the same infrastructure as a SaaS product. Recognising that line is a product skill as much as a technical one.

More like this, straight to your inbox.

I write about Frontend and a handful of other things I actually care about. No schedule, no filler — just when I have something worth saying.

If this raised a question, I'd be happy to talk about it.

Find me →
← Back to Learn