Reach for a framework when the problem demands it — not because the ecosystem expects it.
01The honest question nobody asks first
The conversation about which framework to use skips a more important one: do you need a framework at all? A marketing page, a documentation site, a simple form with a thank-you redirect — these are not framework-shaped problems, and shipping React to solve them is a tax on load time, on bundle size, and on every developer who inherits the codebase.
The browser has quietly absorbed a decade of what frameworks once monopolised. Declarative templating with Web Components. CSS custom properties where you once injected JS-driven state. fetch, IntersectionObserver, dialog, popover — a long roster of web APIs that replace whole libraries. Routing, reactive signals, and a component model still require deliberate framework choices. But a surprising amount of what gets built doesn't actually need any of that.
A framework earns its weight when the thing you're building is genuinely stateful, interactive, and navigates between views. When data flows in multiple directions and needs to stay consistent. When a team of five or more people needs a shared mental model baked into the tooling rather than enforced by convention and willpower. These are the conditions that make React or Vue less expensive, not more — because the alternative is inventing the same abstractions yourself, badly, over time.
The trap is treating frameworks as the default and plain HTML, CSS, and a few script tags as the fallback for small projects. Invert it. Start with what the platform gives you. Add a library when a specific gap appears. Graduate to a framework when the complexity of your own coordination code starts costing more than the framework's learning curve and bundle weight would have.