Beyond Vanilla — Where Frameworks Fit In

The problem frameworks solve

Think back to any project where you had to manually keep the DOM in sync with your data: updating a counter's text, toggling a class when a filter changed, re-rendering a list after adding an item. For a small app, writing document.querySelector and manually updating elements is manageable. As an interface grows, with dozens of pieces of state that affect many parts of the page, manually tracking every place the DOM needs to update becomes error-prone and hard to reason about. You end up asking, every time state changes, 'which parts of the page does this affect, and did I update all of them?' Frameworks exist specifically to answer that question for you.

The core idea shared by React, Vue, and Svelte is declarative rendering: instead of writing step-by-step instructions for how to update the DOM when data changes (imperative code, which is what you've been writing), you describe what the interface should look like for a given state, and the framework figures out the most efficient way to update the actual DOM to match. This is conceptually similar to how CSS itself works: you declare what a button should look like, and the browser figures out how to paint it, rather than you issuing pixel-by-pixel drawing instructions. Frameworks bring that same declarative approach to structure and behavior, not just appearance.

1// Vanilla JS2let count = 0;3const button = document.querySelector("#increment");4const display = document.querySelector("#count");5button.addEventListener("click", () => {6  count++;7  display.textContent = count;8});910// React (JSX syntax, compiled by a build tool)11import { useState } from "react";1213function Counter() {14  const [count, setCount] = useState(0);15  return (16    <div>17      <span>{count}</span>18      <button onClick={() => setCount(count + 1)}>Increment</button>19    </div>20  );21}

Notice that the React version never touches document.querySelector at all. It describes the UI as a function of count, and calling setCount tells React that the state changed, letting the framework handle re-rendering the affected part of the page efficiently behind the scenes. This is the same DOM you've always been working with; React (like Vue and Svelte) still ultimately produces real HTML elements, it's just managing the updates for you using techniques like a virtual DOM (React) or compiled reactivity (Svelte) so you don't have to write that logic by hand.

Components: organizing UI the way modules organize logic

You already learned to break JavaScript logic into modules with import and export, each handling one clear responsibility. Frameworks apply that same organizing principle to the UI itself through components: self-contained pieces combining structure, styling, and behavior, like a SearchBar, a ProductCard, or a Modal, that can be reused and composed to build a full page. A component typically accepts inputs (called props) and manages its own internal state, similar to how a class from earlier in the course accepted constructor arguments and tracked instance data. If you're comfortable thinking in terms of classes with private state and clear responsibilities, componentized thinking will feel familiar rather than foreign.

• React uses JSX, an HTML-like syntax inside JavaScript, and manages updates with a virtual DOM.
• Vue uses HTML-based templates with a reactive data system and is often praised for a gentle learning curve.
• Svelte compiles your components into highly optimized vanilla JavaScript at build time, with very little runtime overhead.
• All three rely on component structure, one-way or reactive data flow, and a build tool (often Vite) to compile modern syntax into something browsers understand.

When (and when not) to reach for a framework

Frameworks earn their complexity on larger, more interactive applications, particularly ones with deeply nested state, frequent updates across many components, or large teams needing consistent patterns to collaborate. For a marketing page, a small tool, a blog, or most of the projects you've built in this course, plain HTML, CSS, and JavaScript are often faster to build, easier to deploy, and simpler to maintain, precisely because there's no framework runtime or build complexity layered on top. Experienced developers choose based on the problem's actual shape, not habit or trend, and being able to build confidently without a framework, as you now can, makes you better at recognizing when one is genuinely worth adopting rather than reaching for it by default.