Do You Really Need a JavaScript Framework?
When a new project starts, the first question is usually: "React or Vue? Next or Nuxt? What about Svelte?”. Rarely does anyone ask: "Do we need a framework?”.
Thiago Saraiva
Do You Really Need a JavaScript Framework?
I need to start with an inconvenient truth:
There is no perfect JavaScript framework.
And more importantly: it's very possible that you don't need any.
The Framework Reflex
When a new project starts, the first question is usually: "React or Vue? Next or Nuxt? What about Svelte?"
Rarely does anyone ask: "Do we need a framework?"
This happens because frameworks have become the default. It's like asking "which car will you buy?" when the question should be "do you need a car or can you bike?"
When You DON'T Need a Framework
Consider if your project has:
- Few dynamic interactions — A corporate site with a contact form doesn't need React
- Mostly static content — Blog, documentation, landing page
- Small team — One person can maintain Vanilla JS more easily
- Extreme performance requirements — Frameworks add weight
- Users with slow connections — Every KB matters
Lighter alternatives:
| Need | Alternative |
|---|---|
| Basic interactivity | Vanilla JS, Alpine.js |
| Web components | Native Web Components, Lit |
| Static site | Astro, 11ty (no client JS) |
| Simple reactivity | Petite-Vue, Preact |
When You DO Need a Framework
Frameworks make sense when:
- Complex app with lots of state — Dashboards, SPAs, tools
- Large team — Shared conventions prevent chaos
- Reusable components — Extensive design system
- Frequent UI updates — Lots of reactivity
- Ecosystem — You need specific libraries
The Golden Rule
Start with the assumption that you don't need a framework. Then see how far you can get before realizing you need one.
This applies not just to JavaScript, but to CMSs, CSS frameworks, and any other tool.
The Mental Exercise
Before adding a dependency, ask:
- What exactly does this tool solve?
- What's the cost? (bundle size, complexity, lock-in)
- Is there a simpler solution?
- Does the benefit outweigh the cost?
Simplicity as an Asset
Instead of starting with a complete suite of tools and considerable page weight, consider:
"Simplicity and leanness as an asset. Don't give that asset up unless the benefits outweigh the added complexity and weight."
Every dependency added is a dependency to maintain, update, and eventually replace.
Keeping JavaScript Clean (With or Without a Framework)
Regardless of your choice, some practices improve any codebase:
1. Use Linting
ESLint is not optional. Configure rules that:
- Force
===instead of== - Limit block nesting
- Warn about unused variables
- Ensure consistent formatting
2. Create Reusable Functions
3. Separate Logic from Presentation
4. Document Decisions
Why did you choose (or not choose) a framework? Document it:
The Current Ecosystem
If you decide you need a framework:
| Framework | When to use |
|---|---|
| React | Mature ecosystem, many jobs, many libs |
| Vue | Smooth learning curve, good DX, excellent docs |
| Svelte | Maximum performance, less boilerplate |
| Solid | Fine-grained reactivity, familiar to React devs |
| HTMX | Interactivity without writing JS |
| Astro | Content-first sites, islands architecture |
Conclusion
The question isn't "which framework to use?" but "what problem am I solving?"
If the answer is "I need a carousel and form validation", you probably don't need 150KB of JavaScript.
If the answer is "I need a complex application with shared state, routing, and dozens of interactive components", then yes, a framework makes sense.
A developer's maturity shows not in how many tools they know, but in knowing when not to use them.