Every new side project starts with the same debate: React or vanilla JavaScript? The frontend community has strong opinions on both sides, but most of those opinions are formed by building large production apps. For small projects, the calculus is different. Here is an honest breakdown.
The Five-Question Test
Before picking a framework, answer these five questions from the Solid.js documentation:
- Do you have 3+ components sharing state?
- Do you have 3+ developers on the project?
- Will this project be actively maintained for 2+ years?
- Do you need client-side routing or complex multi-step forms?
- Is this a full single-page application?
If you answered yes to 3 or more, a framework makes sense. If you answered yes to 0-2, vanilla JavaScript is the better choice. Most side projects land in the 0-2 range.
The Bundle Size Reality
A vanilla JavaScript todo app ships at roughly 2KB. The same app in React ships at about 42KB before you write a single component. That is a 20x difference.
For a portfolio site, a blog, or a landing page with some interactivity, that 42KB is pure overhead. The browser downloads it, parses it, and executes it before your users see anything useful. On a fast connection, the difference is unnoticeable. On a mobile connection or in a low-bandwidth region, it is the difference between a fast load and a slow one.
Vanilla JavaScript Got Stronger
In 2026, vanilla JavaScript has capabilities that required React just two years ago:
- Native ES modules — import and export without a bundler
- Fetch API — HTTP requests without axios or jQuery
- Web Components — reusable custom elements with encapsulation
- CSS nesting — no preprocessors needed
- View Transitions API — page transitions that feel native
- CSS :has() selector — parent selection, previously impossible
The gap between vanilla and framework capabilities has narrowed significantly. Many of the features developers reach for React to get are now native browser APIs.
The Maintenance Tax
React 18 to React 19 was a non-trivial migration for many projects. Teams spent weeks updating breaking changes, adjusting to new conventions, and fixing subtle behavioral differences. Meanwhile, vanilla JavaScript code from 2020 still runs unchanged in 2026 browsers.
Frameworks introduce an upgrade treadmill. Each major version potentially breaks your code. Vanilla JavaScript has no upgrade treadmill — the browser handles backwards compatibility.
When Frameworks Win
Frameworks are not bad. They solve real problems:
- Shared conventions — on a team, React patterns prevent five developers from writing five different approaches to the same problem
- Rich ecosystem — thousands of component libraries, state management solutions, and integration patterns
- Hiring — React developers are easier to find than vanilla JS specialists
- Complex state — when you have deeply nested state that updates from many places, React's reactivity model genuinely helps
If your project will grow into a complex application with multiple developers and a multi-year timeline, start with a framework. You will not regret it.
The Hybrid Approach
Architectures like Astro's islands let you ship vanilla HTML with selective framework components. You get the component model where you need it and zero JavaScript overhead everywhere else. This is increasingly where the industry is heading.
The Bottom Line
The decision is not about which technology is "better" — it is about which one fits your specific project. For a weekend project, a blog, or a simple tool, vanilla JavaScript is faster to ship, smaller to download, and easier to maintain long-term. For a growing application with a team, a framework earns its weight. Choose based on your actual needs, not the latest Twitter debate.