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.

More on Frontend

Do not build masks from translucent polygons

A map overlay looked like fog-of-war in theory, but overlapping transparent buffers created ugly rings. The fix was to treat it as one composited mask, not many semi-transparent shapes.

Building a web app for future native migration: constraints from day one

If you're planning to wrap your web app in a native shell later, the constraints aren't optional from day one. Web-only APIs baked into your components will block the migration.

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

Find me →
← Back to Learn