Frameworks, and Where to Go Next

React, Vue, Svelte and their relatives are the most talked-about part of frontend work, and this book left them out on purpose. A framework, in this sense, is a large body of JavaScript that other people wrote, which takes over much of the work of building and updating a page and asks you to write your code in its particular shape. This last topic explains what frameworks actually do, why the platform came first, and where you can go from here.

Learning to drive a car with a manual gearbox first is a fair picture. An automatic is easier to drive afterwards, and you understand what it is doing for you: why it changes gear, why it hesitates on a hill. Someone who has only ever driven an automatic is fine until something behaves strangely. Frameworks are the automatic gearbox; the web platform you have learned is the engine and the gears underneath.

What Problem Do Frameworks Solve?

You have already met the problem, and solved it by hand. In Chapter 8, renderProjects took an array of projects and rebuilt the grid of cards from it. In Chapter 9 the filter buttons chose which projects to show and called it again. In Chapter 11 the projects arrived from a file, and it ran once more. Each time the data changed, you made sure the page was rebuilt to match.

That is the whole problem: keeping what is on screen in step with data that changes. On the site there is one grid, one list and one filter, so remembering to call renderProjects at the right moments is manageable. Now imagine an email app, where the list of messages, the unread count, the folder list and the open message all depend on the same data and on each other. Remembering every place to update, by hand, is where bugs are born.

A framework takes over that bookkeeping. You describe what the page should look like for any given data, and the framework updates the page whenever the data changes, touching only the parts that actually differ, so large pages stay fast.

What Are Components and State?

Frameworks organise a page into components: reusable pieces, each with its own markup, style and behaviour. A project card is a natural component. So is the filter, and so is the grid that holds the cards. You write each once and use it wherever it is needed, the way createCard builds one card for whichever project it is given.

The data that can change is called state: the list of projects, which filter is active, whether a panel is open. The central idea of every modern framework is that the page is a function of its state. Given the same state, the page always looks the same, and to change the page you change the state, never the page directly.

Here is the same feature described both ways. In your site, a click on the CSS filter button runs a listener; the listener filters the array to the CSS projects and calls renderProjects, which replaces the cards in the grid. In a framework, the grid component holds the active tag as state and describes itself as "a card for each project whose tags include the active one". The click sets the active tag to CSS, and the framework notices, works out which cards to add and remove, and updates the page itself. This is the simplified picture: each framework does it differently in detail, but every one of them does this.

Which Frameworks Will You Hear About?

The list changes every few years; the problem does not. As this book is written, four names cover most of the jobs you will see.

React, from Meta, is the most widely used. It writes each component as a JavaScript function that returns something that looks like HTML inside the JavaScript. Vue keeps its templates closer to plain HTML and is often described as the gentlest step up from what you know. Svelte does most of its work before the page ever loads, turning components into small amounts of plain JavaScript during a build step. Angular, from Google, is a larger, more complete framework, common in big companies.

On top of these sit frameworks for whole sites, such as Next.js for React, Nuxt for Vue and SvelteKit for Svelte. They add what a full site needs beyond components: several pages and the links between them, and building pages on a server or ahead of time, so the first view arrives as ready HTML instead of waiting for JavaScript. All of them need the npm and build step of the previous topic.

When Is Plain HTML, CSS and JavaScript Enough?

More often than job listings suggest. Content sites, documentation, portfolios, small tools and anything shaped like your own site work well without a framework, and they are usually faster for it, because the visitor downloads no framework code at all.

A framework earns its cost when many interactive parts share the same data, when the page behaves more like an application than a document, and when a team needs a common structure so that ten people can work on one codebase without tripping over each other. Even then, it produces the same things you learned to write. Every framework's output is HTML, CSS and JavaScript in a browser, so the semantics of Chapter 2, the layouts of Chapters 4 and 5 and the accessibility of Chapter 12 are still your job.

Where Do You Go from Here?

You have built and published a site that is semantic, responsive and accessible, that answers clicks and keys, checks a form, remembers a choice and loads live data. Several directions lead on from here, and they work in almost any order.

To keep a history of your site and update it properly, take Git for Beginners, which teaches Git from zero and, in its chapter on GitHub, how to connect your work to a repository like the one you published. To see the other side of every fetch you wrote, the server that answers it, take Backend Deep Dive. To learn a second programming language, with different strengths, take Python for Beginners. To understand how teams plan, build and ship software together, take Software Development from Zero. And when you are ready for a framework, work through its own official tutorial. With the platform underneath you, you will recognise most of what it does.

A word on learning with an AI assistant. Use it to explain code you are reading and error messages you do not understand; ask it why, not only what. Be wary of letting it write code you cannot yet read, because you will not be able to tell when it is wrong, and it sometimes is. Check its claims against MDN, as you have learned to check everything else.