To Build or Not to Build

srinath shrestha srinath shrestha

There was a time when no-build meant exactly what it said. Drop an .html file. Add some .js. Ship it. Zero configuration, zero bundlers, zero waiting for Webpack to complete its morning rituals.

Why it worked:
Instant feedback — change, refresh, done. Minimal cognitive overhead. Raw files served from a CDN cache, close to the user, with nothing between the file and the browser that could go wrong.

What we did to it:
Frameworks began affixing no-build labels to projects that loaded fifty dependencies on the client before rendering a single element. A semicolon change began triggering cache invalidation, rebuild pipelines, and CI processes that had no business knowing about semicolons. The instant deployment became a two-minute affair because the CDN needed to rehydrate a configuration file written by someone who had forgotten that configuration files are not the product.

The honest position:
Genuine no-build remains the fastest, most legible approach for small, self-contained sites. If the application genuinely requires React-level interactivity and state management, use the appropriate tools. But if the DOM can be addressed directly with plain HTML and JavaScript — that is the correct choice, not the embarrassing one.

Complexity is debt. You either chose it deliberately, or it accumulated while you were looking at configuration files.