There's a question most developers quietly struggle with but rarely ask out loud:
"Which framework should I use — and why?"
Not because they don't care. But because the answer seems obvious until you actually have to make the decision. Then suddenly every blog post, every YouTube video, every Twitter thread is telling you something different.
This article is about cutting through that noise. It's inspired by a Frontend Frameworks Mini-Conference held at LakeHub, organized by Zone01 Kisumu — where we spent a full day tracing the real story of frontend development, from the beginning.
The Beginning: Vanilla JavaScript
Before frameworks, there was just JavaScript. Raw. Unstructured. Completely yours to mess up.
Early web pages were mostly static HTML with a little JavaScript sprinkled on top for basic interactions — form validation, toggling visibility, that kind of thing. It worked. Mostly.
But as the web grew more ambitious — dynamic content, user interactions, real-time updates — writing plain JavaScript became painful. You'd write the same patterns over and over. Managing the DOM directly was tedious and error-prone. Cross-browser compatibility was a nightmare.
Something had to give.
Enter jQuery: The First Real Revolution
In 2006, jQuery arrived and changed everything.
It wasn't a framework in the modern sense — more of a utility library. But what it did was radical for its time: it gave developers a consistent, readable API to manipulate the DOM, handle events, and make AJAX calls, regardless of which browser the user was on.
// Without jQuery
document.getElementById('btn').addEventListener('click', function() {
document.getElementById('message').style.display = 'block';
});
// With jQuery
$('#btn').on('click', function() {
$('#message').show();
});
Cleaner. More expressive. And it worked everywhere.
jQuery dominated the web for years — and honestly, it still powers a massive chunk of the internet today. That's not a legacy problem. That's a testament to how well it solved real problems at the time.
But the web kept evolving. Single Page Applications (SPAs) became the expectation. Users wanted desktop-like experiences in the browser. And jQuery, powerful as it was, wasn't designed for that scale of complexity.
Why Modern Frameworks Became Essential
When you're building a small website, managing the DOM directly is fine. When you're building a complex application with dozens of components, shared state, real-time data, and multiple developers — it becomes chaos.
Modern frameworks emerged to solve specific, concrete problems:
1. State Management
Keeping your UI in sync with your data is harder than it sounds. Change a value somewhere, and every part of the UI that depends on it needs to update. Do this manually across a large codebase and you'll lose your mind. Frameworks automate this.
2. Component Reusability
Write a button once. Use it everywhere. Style it consistently. Pass it different props. Modern frameworks made the concept of reusable UI components a first-class citizen.
3. Declarative UI
Instead of telling the browser how to update the DOM step by step, you describe what the UI should look like for a given state — and the framework figures out the rest.
// Declarative (React)
function Greeting({ isLoggedIn }) {
return <h1>{isLoggedIn ? 'Welcome back!' : 'Please sign in.'}</h1>;
}
Much easier to reason about than imperative DOM manipulation.
4. Developer Experience
Tooling, hot reloading, component devtools, ecosystem support — modern frameworks brought a professional development experience that scales with your team.
The Main Players (and What They're Actually For)
React
Built by Meta. The most widely used. Technically a library, not a full framework — it handles the view layer and leaves the rest to you (routing, state management, etc.). Great for large-scale, interactive applications. Huge ecosystem. High demand in the job market.
Best for: Complex SPAs, applications with lots of dynamic state, teams that want flexibility.
Vue
The approachable one. Gentler learning curve than React, more opinionated than React, but less opinionated than Angular. Often praised for its clear documentation.
Best for: Teams transitioning from jQuery or simpler setups, projects that need a balance of structure and flexibility.
Angular
Built by Google. A full framework with strong opinions about everything — routing, forms, HTTP, state. Verbose, but everything has a place. TypeScript by default.
Best for: Large enterprise applications, teams that prefer convention over configuration.
Svelte
The new-school approach. No virtual DOM — Svelte compiles your components to vanilla JS at build time. Smaller bundle sizes, faster runtime performance.
Best for: Performance-critical applications, developers who want to write less boilerplate.
Alpine.js
The underrated one. Minimal. No build step required. Add it via a script tag and you're done. Handles lightweight interactivity directly in your HTML.
Best for: Adding sprinkles of interactivity to server-rendered pages without pulling in a full SPA framework.
When (and When Not) to Use a Framework
This is the part most tutorials skip. And it's arguably the most important.
Use a framework when:
- You're building a complex, interactive application
- Multiple developers are working on the same codebase
- You need component reusability at scale
- You have significant client-side state to manage
- You're building a Single Page Application
Don't use a framework when:
- You're building a simple marketing site or blog
- The interactivity needed is minimal
- Performance and bundle size are critical constraints
- You or your team aren't ready for the overhead
- A simpler tool (Alpine.js, vanilla JS, even jQuery) solves the problem cleanly
Choosing a framework is not about following hype. It's about solving the right problem with the right tool.
A 400MB React app for a landing page with one contact form is not impressive engineering. It's overengineering. Modern web development has a talent for turning a button into a philosophical crisis — don't let it.
How to Actually Choose
Ask these questions before reaching for a framework:
- What is the complexity of the UI? Simple or highly interactive?
- Who is on the team? What do they already know?
- What is the performance requirement? Does bundle size matter?
- What does the ecosystem need to support? Do you need SSR, SSG, routing?
- What is the maintenance horizon? Will this be around in 5 years?
There is no universally correct answer. React is not always better than Vue. Alpine.js is not inferior to React — it's just for a different job.
Beyond the Framework: How to Actually Think
The most valuable thing you can develop as a frontend engineer isn't knowledge of any specific framework. Frameworks come and go.
What lasts:
- Understanding how the browser works — the DOM, events, rendering
- JavaScript fundamentals — closures, async/await, the event loop
- Component thinking — breaking UIs into reusable, composable pieces
- State management patterns — regardless of which tool implements them
- Performance awareness — knowing what makes pages fast or slow
If your fundamentals are strong, picking up a new framework is just learning syntax. If your fundamentals are weak, no framework will save you.
Final Thought
The evolution from Vanilla JS to jQuery to React to Svelte isn't a story of old tools being bad. It's a story of problems getting bigger and tools rising to meet them.
Every framework exists because someone hit a real wall with what came before. Understanding why a tool was built is the fastest way to understand when you should reach for it.
So next time someone asks "should I learn React or Vue?" — the real answer starts with: what are you trying to build?
This article was inspired by the Frontend Frameworks Mini-Conference hosted by Zone01 Kisumu at LakeHub, Kisumu. Zone01 is a peer-to-peer, project-based coding school — part of the global 01Edu network.