React vs Vanilla JavaScript: When You Actually Need a Framework

React gets reached for by default now, even for projects that don't need it. That's not free — it adds build tooling, bundle size, and a learning curve. Here's how to actually decide.

When plain JavaScript is the right call

• Marketing/brochure websites with mostly static content and light interactivity (a mobile menu, a form, some scroll animations). This is most of what a small business actually needs, and it's this portfolio site's own stack — plain JS, no framework, and it loads fast because of it.
• SEO-critical content sites where you want the simplest possible path to fast load times and easy crawlability, without a JavaScript framework's hydration overhead getting in the way.
• Small, contained widgets — a single interactive component embedded in an otherwise static or WordPress-driven page.
• When your team doesn't have React expertise and the project timeline doesn't allow for the ramp-up.

When React genuinely earns its complexity

• Complex, stateful UIs — dashboards, multi-step forms, real-time data displays — where manually tracking DOM updates in vanilla JS becomes genuinely hard to maintain as complexity grows.
• Applications with many interconnected, reusable UI pieces that need to stay in sync — React's component model and state management solve real, otherwise messy problems here.
• Team projects where multiple developers need a shared, predictable structure to work within.
• Products that will keep growing in feature complexity over months or years — the upfront structure pays off as scope increases.

The honest cost of defaulting to React

A React app for a five-page business site typically means a build step, a larger JavaScript bundle sent to every visitor, and slower initial load compared to a well-built plain HTML/CSS/JS site — a real cost on the mobile networks most Nigerian visitors use. If the interactivity you actually need is a mobile menu and a contact form, that overhead buys you nothing.

A quick test

Ask: does this page need to track and react to changing state across multiple interconnected components? If yes, React is solving a real problem for you. If the honest answer is "not really, it's mostly content with a bit of interactivity," plain JavaScript will be faster to build, faster to load, and simpler to maintain.