How Web Apps Actually Work

You do not need to write code. But you do need to understand the three layers of a web app because that understanding is what lets you describe behaviour clearly to Claude.

This lesson explains the three layers in plain English. No jargon. No code.

The three layers

Every web app is built from three things working together.

HTML is the structure. This is what exists on the page. The input boxes, the labels, the buttons, the area where results will appear. If it exists on the page, HTML put it there. Think of HTML as the skeleton.

CSS is the appearance. This is what everything looks like. The colours, fonts, sizes, spacing, layout, and design. CSS does not change what is on the page. It changes how it looks. Think of CSS as the skin and clothes.

JavaScript is the behaviour. This is what makes the app do things. It watches for what you do such as typing, clicking, and submitting. It processes that information. It changes what is shown on the page as a result. Think of JavaScript as the brain.

When you ask Claude to build a web app it writes all three. You describe what happens. Claude figures out how.

What JavaScript actually does

Five things. Just five. If you understand these you can describe any app behaviour clearly.

It listens for events. An event is something that happens: a click, a key press, a form submission, a page load. JavaScript watches for these and when one happens it responds. "When the user clicks the Calculate button" is an event.

It reads values. It can look at what is in an input field and take that value. "The user typed 50000 in the Annual Income field." JavaScript reads that number and uses it.

It does calculations. It can add, subtract, multiply, divide, round, and compare values. "Take the annual income, divide by working weeks, divide by hours per week, add 30% for expenses." That is all JavaScript arithmetic.

It changes what is shown. It can update any part of the page. It can show something that was hidden, change text, add a new item to a list, or display a result that did not exist before. "Show the calculated hourly rate in the results box" is a display instruction.

It remembers things. It can store information in two ways. While the page is open it uses variables which work like a scratchpad. Between page refreshes it uses localStorage which works like a notebook the browser keeps permanently.

What state means

You will sometimes see the word "state" in web development. Do not be put off by it.

State just means what does the app currently look like and what data does it currently have.

Empty state: the user just opened the app, all fields are blank, and no results are showing.

Filled state: the user has typed their inputs, fields have values, but no result is showing yet.

Result state: the user clicked Calculate and the result is now showing on the page.

Error state: the user clicked Calculate with an empty field and an error message is now showing.

When you describe your app's behaviour to Claude you are describing how the state changes based on what the user does. That is all it is.

localStorage: the browser's memory

localStorage is how your app remembers things between page refreshes without needing a server or database.

Think of it as a small storage box inside the browser. Your app can put things in, take things out, and the data stays there even when the user closes and reopens the page.

It is good for saving a user's to-do list, remembering what they filled in last time, keeping track of a habit streak, and storing quiz results so they can come back and see them.

It is not good for sharing data between different users, storing sensitive information because it is not secure, or storing very large amounts of data.

For the apps in this course localStorage is enough for everything that needs to persist between visits.

What this means for your prompts

When you describe behaviour to Claude think in terms of these six elements.

Event: what does the user do, such as click, type, or submit. Reading: what value does the app read and from which field and in what format. Calculation: what does it calculate and using what formula and producing what result. Display: what does it show and where and in what format. Memory: does anything need to be saved using localStorage. Errors: what happens if they do something wrong and what message should appear.

You do not say "write a function that takes the value from the input." You say "when the user clicks Calculate, take the number from the Annual Income field and divide it by the number in the Working Weeks field."

Claude converts your plain-language description into working code. Your job is to describe the behaviour clearly and specifically.

Your action right now

Look at the planning document from the previous lesson.

Rewrite the behaviour section using the language from this lesson covering events, values, calculations, displays, errors, and memory. Be specific about each step.

This is the language Claude understands best for building apps and it is what makes the difference between a first build that works and one that needs extensive fixing.