Why Frameworks Exist

A page with five moving parts can lie to itself. A checkbox says "done," a counter says "3 open," an empty message still shows, and the bug is not in JavaScript's syntax. It is in the missing system that keeps the screen matched to the facts.

A framework is a tool that gives an app structure: it decides how you describe UI, update state, split files, and connect the pieces. Frameworks exist because hand-updating the DOM works until the page has too many small truths to keep aligned by memory.

From jQuery spaghetti to components

jQuery is an older DOM helper library, a piece of code you call when you want easier selection, events, and effects than the raw browser APIs gave you at the time. It was a huge win. It smoothed over browser differences and made interactive pages practical for a whole generation of developers.

The problem was not jQuery itself. The problem was the style many apps grew into: handlers reached across the page and patched whatever needed patching.

const taskId = Number(button.dataset.id);
 
$(`#task-${taskId}`).addClass("is-done");
$(`#task-${taskId} input`).prop("checked", true);
 
const openCount = Number($("#open-count").text()) - 1;
const doneCount = Number($("#done-count").text()) + 1;
 
$("#open-count").text(openCount);
$("#done-count").text(doneCount);
$("#empty-message").toggle(openCount === 0);
$("#debug-state").text("Task marked done");

This is spaghetti code, code whose paths cross so much that changing one feature tugs on several others. One click handler changes a row, a checkbox, two counters, an empty message, and a debug panel. Add filtering, loading states, undo, keyboard shortcuts, and server saves, and the code becomes a room full of people updating separate whiteboards from memory.

A component is a small UI unit that owns one piece of rendering logic, like a task row, toolbar, or search box. Components were the escape hatch from page-wide selector choreography. Instead of "find these seven nodes and patch them," you start thinking, "this small part receives facts and describes what it should show."

You already built the loop

Back in State → Render: UIs Without a Framework, you built the key idea by hand:

event happens
update state
render(state)

That loop is the heart of the component era. Synchronization is keeping related pieces matched after a change, and state → render gives you a clean way to synchronize UI: the state object is the single source of truth, and the DOM is a disposable display of that truth.

The win is not that frameworks make state disappear. They make state changes easier to route through one system. When the task changes, the pieces that describe that task can update from the new facts instead of trusting every handler to remember every DOM node.

Try it - feel the hand-built loop

This playground does not run a framework. It uses plain JavaScript to print a tiny "screen" from state. Run it, then change the filter from "open" to "all" and run again. You are doing manually what frameworks make routine.

Notice the pressure. You need a state shape, update functions, a render function, and a rule that every event follows. That is fine for a lesson-sized app. On a product screen with forms, tabs, network loading, validation errors, permissions, animations, and team-owned files, you want stronger machinery.

What frameworks actually solve

Frameworks solve repeated UI synchronization work.

They give you a component model, so the app is not one long script touching a whole page. They give you state-update rules, so changes flow through a known path. They handle rendering, scheduling work, which means deciding when updates should run so the browser can stay responsive, and updating only the parts that need attention. They also bring conventions: file layouts, dev tools, routing patterns, testing helpers, package ecosystems, the surrounding packages and community habits other developers recognize.

Here is the shape, not the full syntax lesson. JSX is HTML-shaped JavaScript syntax used by React and some tools to describe UI:

function TaskList({ tasks }) {
  const openCount = tasks.filter((task) => !task.done).length;
 
  return (
    <section>
      <p>{openCount} open</p>
      <ul>
        {tasks.map((task) => (
          <TaskRow key={task.id} task={task} />
        ))}
      </ul>
    </section>
  );
}

Do not worry about the braces yet. Read the shape: facts go in, a piece of UI comes out, and a smaller component handles each row. That is the component idea wearing React clothes.

What frameworks cost

A framework is not free power. It is an abstraction, a simpler surface that hides lower-level details, like a dashboard that hides the engine until a warning light turns on.

You pay by learning the framework's rules: when rendering happens, how state updates work, where files belong, how data loads, how effects clean up, and what the toolchain expects. You add dependencies. You inherit upgrade work. You debug through another layer when something breaks. You also accept opinions, which can be helpful on a team and annoying when the app wants a different shape.

The mature view is not "frameworks are magic" or "frameworks are bloat." It is this: use the platform until the coordination cost is higher than the framework cost. A static page does not need a component system. A task board with shared state, routes, server data, tests, and a team probably does.

That is why this course taught the platform first. You can now see the bargain clearly: frameworks industrialize patterns you already understand. Next, React gets the spotlight, and JSX, props, useState, and useEffect become names for moves you have already earned.