Static sites, frontend, and backend

Two sites on screen. The first is a page with a game: a board, a score, a "restart" button. The second is a repair shop page with a "place an order" form. Both open in a browser, both are built from HTML, CSS, and JavaScript, both look finished. The first one ships in a minute: folder to a host, link ready. With the second one, the agent will most likely stop and ask where the server will be and where the orders should be saved.

The difference isn't complexity, and it isn't looks. It's about who has to do something when a visitor clicks a button, and where the data has to end up afterwards. Let's go through three words - static site, frontend, and backend - and see where data lives and why that decides how you publish. At the end we'll look at what the agent asks on its own before you say "ship it", and what's worth asking it yourself.

1. A static site

A static site is a site made of ready-made files: index.html, style.css, scripts, images, fonts. The server stores them and hands every visitor the same ones, computing nothing and remembering nothing about the visitors. The visitor's browser does all the work - drawing, counting, reacting to a click - on their own computer.

Take a one-page portfolio. The folder holds index.html with a few words about you and a list of your work, style.css, a dozen images, and a small script. A visitor opens the link; the browser downloads the files and builds the page out of them. Clicking a project opens a larger image; the dark-theme toggle changes the colors: that's the script in the browser. Once the server has handed over the files, it takes no part in what happens next - it doesn't care who came or what they clicked. New project to show? You edit index.html, put the image next to it, and ship the folder again; there's no other way to change anything here, and it's you who changes the site, not the visitor.

The same goes for:

• an event page for a concert or a meetup: date, place, schedule, directions; the "buy a ticket" button leads to the ticket seller's site, and the page itself sells nothing;
• a landing page for a product or a service, if it lists a phone number and an email instead of a form;
• project documentation: dozens of pages with a menu and links to each other, and still just files;
• a blog with no comments: every post is a file, and a new one ships the same way as everything else;
• a browser game. Yes, a game too: moves, score, and animation are all computed in the browser, and the server doesn't care about them.

You can see where static ends if you split the site's work into two halves: the part the browser does and the part the server does. Both halves have names.

2. Frontend runs in the browser

The frontend is everything that runs on the visitor's computer: the markup, the styles, and the scripts the browser received and ran on that machine. The "front part", the one you can see. (People often call it "just the markup", but it's the whole part of the site a person interacts with, and on a static site it's the entire site.)

The frontend can do plenty: draw the page, count moves in a game, check that a form field isn't empty before sending, remember something until the next visit - the browser has its own storage for that, and the agent will call it localStorage. What it can't do is share. That storage lives in this browser on this device, and nowhere else. Two examples show where the boundary gets in the way and where it doesn't.

The high score in a game. The round is over. The script compared the result with the previous record and wrote the new one into browser storage. Tomorrow the player opens the page in the same browser on the same laptop and the record is there. On a phone it's empty, because the phone has storage of its own. You, the author of the game, will never see that record. And that's fine: it only matters to the player, and the site stays static.

An order for the repair shop. The customer described what needs doing, left a phone number, clicked "send". The script can check that the fields are filled in, and after that it has nowhere to go: write the order into browser storage and it stays on the customer's phone, and the shop never hears about it. The order has to be read by another person on another device, so the data has to leave the customer's computer, and someone at the other end has to receive it and save it. A site made of files alone has no such "someone".

The frontend handles anything that concerns one visitor on one device by itself. The rest is the other half's job.

3. Backend runs on the server

The backend is a program that runs on a server and answers requests from browsers. Take an order and save it. Check a login and a password. Return a list of products. It keeps working after the visitor has closed the tab, and it has to be running all the time, just like the server itself - a computer nobody turns off.

The diagram shows two paths of the same shape: click, work, result. They differ in the middle box - who does the work and what work exactly. On top, after a move in the game, JavaScript in the browser counts the score, saves the record and redraws the board, all of it on the visitor's computer. Below, a click on "send" turns into a request, the request goes to the server, and the program receives it, saves the order on its own server and answers the browser, and it's that answer that reaches the screen. Where exactly on the server the order sits - that's the next section. The question "who does the work" is the line between the two kinds of sites.

Three recognizable signs that you can't do without a backend:

• logging in with a password: someone has to store the passwords and check them, and it can't be the visitor's browser;
• data that other people have to see: comments, orders, a shared list;
• an action taken on your behalf: send an email, process a payment, write something into another service using your key.

A backend can be written in any language: JavaScript (Node.js in that case), Python, Java, a dozen others. For this article, what matters isn't the language but the fact that the program has to run somewhere all the time, and that "somewhere" isn't a browser. The site address leads to a place on a server, same as with static files, except that place now holds a program instead of a file, and the program builds the answer on the fly.

4. Where data lives

The data decides who has to do the work after a click: where it sits and who has to see it. Not how the site looks, and not how complex it is. Three places.

In the project files. Page text, images, the rules of the game. The same for every visitor, and they change only with a new deploy: edit the file, ship it again.

In the visitor's browser. Settings, the high score, a form draft you'd rather not lose on reload. Only this visitor on this device sees it. It disappears when site data is cleared; it isn't there in a private window, nor in another browser or on another device, and you know nothing about it.

In a database on the server. Orders, comments, accounts. Everyone who is supposed to see it does, you included. It stays there whether or not anyone has a tab open. To get something in there you need a program on the server that receives the data and writes it.

The diagram shows the same two worlds as the one above, except that this time they show where the data lives rather than who does the work. Every visitor gets a copy of the site files, which is why the page is the same for everyone. Browser storage is the only box with no arrows: the data is in there, but it never leaves the device, and you won't see it. Data gets into the database only through the program, but from there the right people can all see it.

Instead of theory, ask one question: does another person have to see what this person typed in? "Remember the high score" - no, so browser storage it is, and the site stays static. "Save the order" - yes, so a database and a program that writes into it. The question has one exception, and it isn't about data: a key to someone else's service. If there's a key, the answer "no" doesn't save you: it can't sit in the files, so you need either a program on the server that talks to that service on your behalf, or a third-party service that does it for you.

There's a middle ground. Someone else's service can receive the order form for you: the visitor clicks "send", the data goes to them instead of your server, and reaches you as an email. That's still a backend, just not yours. The agent will name one if you ask; what matters now is that a form doesn't work without somebody's program on a server.

5. Why deploying differs

You publish static files by copying them: the folder goes to a hosting service (someone else's server that hands your files to anyone who asks), the link is ready, and to update the site you copy the folder again. That's it.

With a backend it's different. The server needs the runtime for the program's language installed - Python or Node.js itself; without it there's nothing to run the code with. The program has to be running, and it has to restart if it crashes. A database has to run next to it. Keys to the database and to other services have to sit where the program can read them and visitors can't. Each of these parts is updated separately and breaks in its own way.

Hence a different kind of hosting: one that runs programs rather than just handing over files. There you usually pay for the time the program is running and for the space the database takes. Free options exist, but with terms that change more often than this article.

One clarification on the secrets row. A static site does have a hosting key, if you set one up for a permanent link, but it lives apart from the site folder and never goes into it.

"Spin up a server" sounds routine in the agent's answer, like "create a file". Behind that phrase is the entire right-hand column of the table, and almost every row will need maintaining later.

6. Where to publish a static site

Since you publish static files by copying them, there are plenty of hosts for them, and most are free for a small page. Here are the five you'll run into most often. The word "repository" shows up in the table: for now it's enough to read it as the project folder under version control, details some other time.

How to choose. To show something and talk it over - the one that gives you a link without signing up. To keep it around - any of them where you have an account. Project already in a repository - the one that connects to the repository and updates itself on every change. The choice doesn't affect how the published page looks: the files are the same.

If the site has a backend

A program needs hosting that can do more than hand over files: it has to start your code and keep it running. What it asks for isn't a folder but a program, and it installs the runtime itself. Some of the services in the table above have that mode too, but people usually start with two that were built for programs:

A free backend always has a price of its own: on one service the program falls asleep, and the first visitor after a pause waits for it to wake up; on another the credit runs out. Once there are a lot of visitors, you start paying for keeping it running. Static files have no such problem: files don't sleep.

Terms and limits change at every service, and products get renamed and merged: Cloudflare, for example, now suggests starting new projects in Workers rather than Pages, and static files are published there the same way. We deliberately kept numbers out of both tables: check the pricing page before you choose.

7. What to ask the agent before publishing

The agent looks at the folder and usually names the project type itself. Files and no program, and it will suggest static hosting, even if one of those files is a form with nowhere to send what it collects: it doesn't always spot that. A server.js or an app.py, and it will say a server is needed and ask where that server will be. If it didn't say, or said it too fast, ask it yourself:

Look at the project and tell me whether this is a static site or whether it needs a server.
List exactly what requires a server, point by point.
For each point, suggest whether it can be done without a server or postponed.

The answer depends on the project, so it isn't printed here. There are, though, a few things worth looking at in any answer.

• Don't accept "you need a server" without looking into it. Ask what exactly requires it and whether that can be done in the browser or postponed - for example, ship the first version without the form. The agent is happy to build a backend where browser storage would have been enough.
• And the other way around: if the data has to be shared, the agent will most likely say that static files aren't enough. That isn't extra complexity; it's calling things what they are. nothing to argue with here.
• As for a key to someone else's service, the agent will ask where to put it. The answer "into a site file" is wrong, and a good agent will say so itself. Such keys have a place outside the site files, and the agent should name it on its own rather than offer to write the key into the page.
• To deploy static files the agent needs a folder. To deploy a backend it also needs answers about the database, the runtime, and the secrets. If there were no questions and the server "spun up" anyway, look at what exactly it did and where.

The words "static" and "backend" describe a place, not a level of complexity: where the work happens and where the data lives. Once that place is known, the way to publish picks itself.

Hosting terms change over time; check the pricing pages.