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. 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. 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. 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: 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. 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. 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 {isLoggedIn ? 'Welcome back!' : 'Please sign in.'}; } Much easier to reason about than imperative DOM manipulation. Tooling, hot reloading, component devtools, ecosystem support — modern frameworks brought a professional development experience that scales with your team. 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. 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. 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. 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. 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. This is the part most tutorials skip. And it's arguably the most important. 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 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. 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. 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. 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.