When to reach for a framework and when to stay vanilla

Frameworks exist because certain problems come up in almost every application: routing, state management, component re-use, form handling. A framework is a solved version of those problems, packaged for reuse.

The question is: do you have those problems?

The Hidden Cost of a Framework

Every framework you adopt is a dependency. Someone wrote it, made decisions about how it works, and those decisions now constrain your code. When the framework makes a decision you disagree with, you have two options: work around it (complex) or replace it (expensive).

Frameworks also have bundle size. React, Vue, Angular—all of these add weight to your JavaScript bundle. For simple pages, that weight is not justified.

When Vanilla JS Is Enough

• A landing page with a contact form and a hamburger menu: vanilla JS
• A dashboard with a few interactive widgets: vanilla JS + the browser's fetch API
• A blog with syntax highlighting: vanilla JS

// No React needed for a mobile nav toggle:
document.querySelector('.nav-toggle').addEventListener('click', () => {
    document.querySelector('.nav-menu').classList.toggle('open');
});

This is 3 lines. The React equivalent is a component, state, conditional classes, and a bundler.

When You Actually Need a Framework

• Complex state that changes frequently: React's reconciliation algorithm handles DOM updates efficiently at scale
• Many interactive components sharing state: without a framework, prop drilling and event coordination become unwieldy
• A large team with a large codebase: frameworks provide conventions that make code navigable across people

The Question to Ask

'Is the complexity of this framework less than the complexity it eliminates?' For a static marketing site: no. For a SPA with 50 views and complex user flows: yes.

Start smaller than you think you need. Add the framework when its absence is the actual pain.