Behaviour

On Deezer, tap the heart next to a song and it fills in at once, while the music keeps playing. The page didn't reload: a script changed it in place.

When a page loads, the browser reads the HTML and builds a live copy of the page in its memory: a tree of all the page's parts, each heading, list, button and picture, which developers call the DOM. The screen is drawn from that tree. Scripts, the JavaScript files the page loaded, can change the tree while the page is open: update a number, add a line to a list, hide a message, swap an icon. The browser then redraws only the part that changed.

So a page has two versions. "View page source" shows the HTML the server sent. Inspect, in the developer tools, shows the live tree as it is right now, after the scripts have worked on it. When you edit a headline with Inspect, you're editing that live copy in your own browser, and a reload brings the real one back.

Scripts spend most of their time waiting. When the page loads, a script leaves instructions with the browser: "when someone clicks this heart, run this code", "when someone types in the search box, run that". Developers call each one an event listener, and what happens is an event: a click, a key pressed, a form sent, the page scrolled. Nothing runs until the event, and then the code runs every time it happens.

You can see them. Select an element with Inspect and open the Event Listeners tab: it lists what the page is waiting for on that element, with the script and the line that will run. If the script fails to load, nothing is listening: the heart looks exactly the same, and tapping it does nothing.

Plenty of movement needs no script at all. A button that changes colour when the mouse passes over it, or a menu that slides in, is often plain CSS, which the browser handles by itself. Scripts come in when something has to be computed or remembered, such as a total or a filter.

A change on screen tells you nothing about what the company knows. When you add a jacket to your favourites on Vinted, the script first changes your copy of the page, in your browser. Vinted's servers learn about it only if the script also sends them a message, which it can do in the background as soon as you tap, or later, at checkout for instance.

Sites choose differently. Many send each change to the server at once, so your favourites or your basket follow you to your phone. Others keep the basket in the browser until checkout, and it's gone when you switch device. You can find out which kind you're dealing with in a minute: make the change while logged in, then open the site on another device with the same account. If the change is there, the server knew.

The same idea explains why editing a page with the developer tools does no harm. You can change a price on any shop's page and the shop never hears about it. When you order, the server works out the price again from its own catalogue.

You read a new message in a marketplace app, yet the red badge on the envelope still says 1. You remove a song from a playlist, and the header still counts 25 titles while the list shows 24. The screen disagrees with itself, because of how the code is organised.

Built the quick way, the same information is shown in several places, and each action updates each place by hand: "when a message is read, mark it in the list, then change the badge, then change the tab's title". Every new button, and every new place that shows the number, adds something to remember in every other action. Sooner or later someone forgets one, and each patch adds another thing to remember.

The lasting fix turns it around. The data lives in one place, called the state: the messages and whether each one is read. Actions only change the state. Then one piece of code redraws everything that depends on it after every change, so nothing is forgotten. Developers write it "UI = f(state)": the screen is a function of the data. When the same kind of bug keeps coming back, ask for this structure, since even careful developers forget.

React, Vue and Svelte are frameworks: ready-made code that redraws the screen from the state automatically. That's the main reason they exist. They pay off when many things on screen change while the page is open and depend on each other, as in a seat map on SNCF Connect or a shared calendar.

They also have a cost. A framework project needs a build step, a program that turns the developers' code into files the browser can run, and a list of dependencies, other people's code, that must be updated regularly. Every later change needs a developer who knows that framework. And a framework site built carelessly sends an almost empty page and fills it in with JavaScript, so when the script fails, visitors and search engines get nothing. Tools such as Next.js or Astro can send ready-made pages from the server to avoid that.

A city hall's pages of opening hours and procedures barely change while you read them, so a framework would solve a problem they don't have. Responsive layouts and animations come from HTML and CSS. And "modern" is no reason to pick a tool: the simplest one that does the job is.

These work with an agency, a freelancer, or a colleague building with an AI agent.

For any feature that changes the page, ask what the server learns, and when: at once, at checkout, or never. If something should follow users to their phone, check it on two devices yourself. When the screen disagrees with itself, ask where the data lives and whether every display is redrawn from that one place. If it's the second bug of the same kind, ask for the structure to be fixed along with the bug, and for an automated test that checks every display after every action.

When a proposal names a framework, ask what on the page changes enough to need it, what it costs to keep up to date, and who will make changes once the developer has left. React only builds the interface in the browser, so ask who provides the rest: hosting, a server, accounts, a way to edit the content. And if the pages are built by scripts, ask what visitors and search engines see when a script fails.