Zero-Dependency vs Framework: Shipping a Tool as One HTML File
We reach for a framework by reflex now. New tool? create-react-app, or Vite, or Next. But for a whole class of focused tools, the right answer is nothing — no framework, no build step, one HTML file. I shipped a 3,000-item interactive tool this way and want to lay out the tradeoff honestly, because it's not always the right call.
What you gain going zero-dependency
Portability. One file that runs on any OS, in any browser, offline, forever. No hosting, no deploy, no runtime to keep current. You can email the product.
Longevity. A vanilla JS file written today will run unchanged in ten years. A framework app accrues maintenance debt — dependency updates, breaking changes, deprecations — from the day you ship it.
No supply chain. Zero node_modules. Zero transitive dependencies to audit or patch. The security surface is your own code and nothing else.
Instant load. No bundle to parse, no hydration. The file opens and it's interactive.
What you give up
Component ergonomics. No JSX, no reusable component model. You're writing document.createElement and managing your own render calls. For complex UIs this gets old fast.
Reactivity. No automatic re-render on state change. You call your render function manually when state changes. Fine for simple state; painful for deeply interdependent UI.
Ecosystem. No component libraries, no router, no state management. You build what you need or do without.
The deciding question
Ask: how complex is the state, really? A filterable list with a few toggles and localStorage persistence? Vanilla is not just adequate, it's better — you'd be adding a framework's weight and maintenance cost for a UI that a render function handles in fifty lines. A collaborative, real-time, deeply-nested-state app? Use the framework; you'll need it.
My tool is a searchable library plus a form-like builder. The entire "state" is a handful of module-scoped variables and a Set of favorites. A framework would have been ceremony around a problem that didn't need it.
The heuristic
If the tool could plausibly be described as "a page that filters some data and remembers a few things," ship it as one file. If you're reaching for words like "workflow," "collaboration," or "real-time," reach for the framework.
A concrete example
The free Seedance Prompt Composer demo is the zero-dependency approach in production — one file, no build, runs offline. Open the source; it's a readable reference for how far vanilla gets you before a framework earns its place.
Top comments (0)