Vanilla HTML vs Frameworks: How to Decide
When plain HTML is enough, when frameworks actually help, and how to avoid choosing tools out of fear.
Hello once again. It’s been a while since my last post, but I’m back with another one.
Today I want to talk about a topic that refuses to die in frontend development, a debate I’ve seen in job descriptions, interviews, and endless online arguments:
Vanilla HTML vs Frameworks.
I’ve had to think about this a lot in my own journey: the pros, the cons, when to use each approach, when not to, and why there’s no universal “right” answer, even in 2026.
Let’s get into it.
Where most developers start
If you’re getting into frontend development, chances are you started with vanilla HTML, CSS, and JavaScript; this is normal as it’s the foundation of the web.
At some point though, as projects grow, frameworks enter the conversation. They promise speed, structure, and scalability. Sometimes they deliver. Sometimes they just add weight.
I learned this the hard way across multiple projects: starting simple, then slowly realizing that what was once manageable had turned into a mess of state, logic, and edge cases.
That’s usually where this debate begins.
The two sides of the argument
There are usually two loud sides when it comes to this debate:
- One side says vanilla HTML is enough and frameworks are unnecessary bloat.
- The other side says frameworks are the only way to build modern web applications.
Someone builds a landing page with plain HTML and CSS and declares frameworks dead.
Someone else ships a massive app in React and wonders how anyone survives without one.
Both are right.
Both are wrong.
The real mistake isn’t choosing HTML or a framework.
It’s choosing by habit instead of by constraint.
Vanilla HTML is not “beginner tech”
This needs to be said clearly.
HTML, CSS, and a bit of JavaScript are not basic or beginner tech, JavaScript on its own is a powerful language which can be a headache to work with on large scale projects. They’re the foundation. Most websites and web apps on the internet still run on them, quietly, efficiently, and without drama.
If your project is:
- Mostly static
- Content-heavy
- SEO-driven
- Light on interaction
- Maintained by one or two people
Then vanilla HTML is not a compromise. It’s the correct solution.
Frameworks don’t make simple things better. They make them heavier. Running React or Vue just to render static content is rarely a good trade-off.
Frameworks exist for a reason
Frameworks didn’t appear because developers hate HTML. They appeared because complexity became unavoidable.
If your project involves:
- Constant state changes
- Tangled, dynamic UI logic
- Multiple developers touching the same codebase
- Long-term maintenance
- Behavior closer to “software” than “website”
Then structure matters more than elegance.
Frameworks provide conventions, guardrails, and shared mental models. You trade simplicity for predictability. You pay for that with setup cost, abstraction, tooling fatigue, and the need to unlearn and relearn patterns over time.
Sometimes that trade is worth it. Sometimes it isn’t.
The hidden cost nobody counts
Frameworks don’t just add dependencies. They add decisions.
- Build tools
- State management
- File structure
- Upgrade paths
- Breaking changes
- Ecosystem churn
If you don’t need those decisions, you’re importing stress for no reason.
Vanilla HTML rarely breaks because someone changed a version number or updated a library.
The fear-driven choice
A lot of developers reach for frameworks out of anxiety.
“What if this grows?”
“What if I need it later?”
“What if this looks unprofessional?”
This is backwards thinking.
You don’t future-proof by overbuilding.
You future-proof by staying adaptable.
It’s far easier to introduce a framework later than it is to remove one.
The real questions to ask
Not “Is vanilla enough?”
Not “Which framework is best?”
Ask instead:
- How long will this live?
- Who will maintain it?
- How complex will the behavior actually be?
- What happens when I stop working on it?
Tools don’t make projects scalable. Decisions do.
Being boring actually works
Starting simple is not laziness; it’s discipline.
When I built my portfolio site, vanilla HTML, CSS, and JavaScript were enough. As I added forms, animations, and more complex interactions, the cost of maintaining everything manually increased. That’s when a framework made sense.
Same thing happened with freetools.org.
It started as a simple collection of tools built with vanilla tech. Over time, it required external integrations, a secure backend, performance optimizations, and features that would have been painful to manage without structure. At that point, a framework wasn’t “nice to have.” It was necessary.
The switch wasn’t ideological. It was practical.
Final thought
Choosing vanilla HTML or a framework isn’t about being “modern” or “old-school.”
It’s about respecting the problem in front of you.
Overengineering wastes time.
Underengineering wastes trust.
Good developers learn to tell the difference.