The Framework Default That Costs More Than It Saves
The default in modern web development has become framework-first: when a new web project starts, the first decision is often which JavaScript framework to use rather than whether to use one. This default has produced a generation of web projects where a simple website serves hundreds of kilobytes of JavaScript framework code to render HTML that could have been served as static HTML, loads more slowly than it needs to, and requires framework knowledge to modify rather than the standard HTML, CSS, and JavaScript that any web developer knows.
Frameworks add genuine value for specific application types. They add unnecessary complexity, JavaScript bundle size, and maintenance overhead for projects that don’t need what frameworks provide. The question ‘should I use a framework for this?’ deserves a genuine answer rather than an assumed yes.
What Frameworks Actually Provide
JavaScript frameworks (React, Vue, Svelte, Angular) provide specific capabilities that become valuable at specific levels of application complexity: component-based architecture (reusable UI components that encapsulate markup, styling, and behaviour), reactive state management (UI automatically updates when underlying data changes without manual DOM manipulation), efficient rendering (virtual DOM diffing or compiler-optimised updates that perform better than naive manual DOM manipulation in complex scenarios), and ecosystem integration (routing, state management, server-side rendering in meta-frameworks like Next.js and Nuxt).
The critical word: ‘complex.’ These benefits are most meaningful in applications with significant interactive complexity — forms with validation that affects many UI elements simultaneously, real-time data that updates the UI automatically, complex state that’s shared across many UI components, or applications where many users need to collaborate in real time on shared state. For simpler use cases, these capabilities aren’t needed, and their costs (bundle size, build tooling, framework-specific knowledge) aren’t offset by the value they’d provide.
When Vanilla JavaScript Is the Right Choice
Vanilla JavaScript (standard browser JavaScript without any framework or build step) is the right choice for: static or largely static websites where interactivity is limited to a few independent behaviours (a navigation menu, an image carousel, a form with basic validation), browser extensions where bundle size and startup time are critical, small widgets or embeds that need to work in diverse host environments without framework overhead, and proof-of-concept work where the build tooling overhead of a framework adds time without adding capability.
Modern browser JavaScript is powerful enough that the ‘vanilla JS is too limited’ argument that was valid in 2015 is much less valid in 2026. Fetch API for HTTP requests, CSS custom properties for theming, the full DOM API for manipulation, and native browser APIs for storage, routing, and more provide the capabilities that developers used to reach for jQuery and frameworks to access. A website that doesn’t need reactive state management or reusable stateful components doesn’t need a framework to be well-built.
The Performance Case for Vanilla JS
The performance difference between a framework and vanilla JS at comparable complexity levels is significant and directly affects user experience and Core Web Vitals. A vanilla JavaScript page that provides equivalent functionality to a React page might deliver 10-50 KB of JavaScript rather than 130-180 KB (the minimum bundle for a React application including React itself). On a slow mobile connection, this difference is measurable in seconds of load time.
The performance argument is strongest for content websites and marketing pages that prioritise Core Web Vitals and fast initial load over application-level interactivity. A company homepage built with React because ‘we use React’ and containing mostly static content is delivering a poor page weight to performance ratio; the same homepage as HTML with vanilla JavaScript for any interactive elements would load faster and rank better on performance metrics.
The Practical Decision Framework
The questions that determine the right choice: Does the project have significant shared state that multiple UI components need to react to simultaneously? (Yes: framework likely appropriate). Will many similar UI components need to be created and reused? (Yes: framework’s component system adds value). Is this primarily a content site with limited interactivity? (Yes: vanilla JS or a static site generator is likely more appropriate than a full framework). Is a team already proficient in a specific framework? (Yes: the productivity benefit of an already-known framework may outweigh the overhead cost for a team that would otherwise learn a new tool).
The answer that’s increasingly available for complex projects that want framework capability without framework weight: Astro (a static site builder that ships zero JavaScript by default and adds island-based interactivity only where needed), HTMX (a library that extends HTML with AJAX, websockets, and CSS transitions without requiring a JavaScript component model), and the progressive enhancement approach (start with working HTML, add JavaScript for enhanced behaviour rather than requiring JavaScript for basic functionality). These approaches provide a middle path between full-framework overhead and vanilla JS’s lack of structure for larger projects.