Web Development Basics

Your First Web App

How to decide when a project can stay static and when it needs a backend.

A Useful Distinction for Early Web Projects

The phrase "web app" covers too much ground, since a single HTML file and a multi-user service with authentication are often described with the same term. The early distinction is about what has to happen on the server (a computer somewhere on the internet that responds to requests from browsers) before a page reaches the visitor. A static site sends the same files to every visitor. A backend-powered app generates responses on the server, often drawing on user data, stored state, or protected credentials. The difference matters for hosting, for complexity, and for how much preparation you need.

The Three Languages of the Web

Every website you visit is built from three languages that run in the browser (the application on the user's own computer, such as Chrome or Firefox). An agentic coding tool can generate all three from a natural-language description of what you want. The page you are reading now was built that way, with no database or backend involved.

The three building blocks

HTML: structure and content
CSS: presentation and layout
JavaScript: interactive behavior in the browser

A minimal HTML file illustrates the point. The following is a complete web page, ready to open in a browser:

            html
            <!-- This is a complete, working web page -->

            <html>

              <head>

                <title>My Page</title>

                <style>

                  body { font-family: sans-serif; padding: 2rem; }

                </style>

              </head>

              <body>

                <h1>Hello, world</h1>

                <p>This file works by itself. No server needed.</p>

              </body>

            </html>

Save that as a .html file and double-click it. It opens in your browser, which means you already have a functioning web page.

Static Sites

A static site is a collection of files delivered to the browser exactly as they are. The server does no computation per visitor. It hands over HTML, CSS, and JavaScript, and the browser handles rendering, layout, and any interactive behavior on its own. Most of the projects that beginners build with agentic coding tools fall into this category.

How a static site works

Browser

→

HTML / CSS / JS files

→

Browser renders page

The browser requests files, the server sends them, and nothing else has to happen.

Common static site projects

Guides and documentation, like this page
Portfolios and project showcases
Data visualizations: charts and interactives built with JavaScript
Landing pages: event announcements, workshop descriptions
Digital exhibits: curated collections with images and text

Static sites can still be highly interactive. JavaScript running in the browser can filter data, animate charts, respond to clicks, and call external APIs (services that let one program request data from another), all while the underlying files are being served as-is. The word "static" refers to how the files are delivered, not to what the page can do.

When You Need a Backend

A backend is code that runs on the server, written in Python, JavaScript, Ruby, or another language. The browser never sees this code; it only sees the responses the server sends back. You need a backend when the project has to save shared state, protect secrets, authenticate users, or process sensitive data. Ask whether the project needs to remember things, keep secrets, or coordinate between users. If so, you need a backend. The project will take more work to build and host.

Signs you need a backend

Users log in: authentication requires securely storing and checking credentials on the server
Data persists between sessions: comments, form submissions, saved preferences
Credentials must stay hidden: API keys (passwords that let your code talk to an external service), database passwords, or anything that would be exposed if it lived in browser code
Multiple users share data: a collaborative tool, a shared reading list, a comment system

How a backend-powered app works

Browser

→

Server (backend code)

→

The browser talks to the server, the server talks to the database, and the server sends back a response.

Quick Comparison

	Static Site	Backend App
Hosting	Free or near-free (GitHub Pages, Netlify)	Requires a server or managed platform
Data storage	Browser only (localStorage, a small scratch pad on the user's machine)	Server-side database, shared across users
Credentials	Visible in source code	Hidden on the server
Moving parts	HTML/CSS/JS files	Files + server code + usually a database
Typical projects	Documentation, portfolios, data visualizations	Search engines, collaborative tools, anything with user accounts

The Gray Area: APIs and Third-Party Services

There's also an in-between case. A static site can call a public API directly from the browser. The server-side work happens on someone else's infrastructure, and your project is still just a set of flat files. You could query the OpenAlex API for scholarly articles or the Library of Congress API for catalog records, with the JavaScript in your page making the request and displaying the results. Many library-adjacent projects fit this pattern.

The following JavaScript, running inside a static HTML page, fetches search results from OpenAlex without any backend:

            javascript
            // Runs in the browser, no backend needed

            const response = await fetch(

              'https://api.openalex.org/works?search=digital+humanities'

            );

            const data = await response.json();

            // Now display the results on the page

            document.getElementById('results').innerHTML =

              data.results.map(work => `<p>${work.title}</p>`).join('');

This approach works well when the API is public and requires no authentication. It does not work when you need to hide credentials or coordinate state across users. Some APIs also impose CORS restrictions (a browser security policy that blocks requests to domains other than the one serving the page), which can force you toward a small backend even for otherwise simple tasks. You may run into these restrictions mid-project.

Working with APIs and External Data takes up this boundary in more detail, including documentation conventions, CORS workarounds, pagination (the common pattern where an API returns results in chunks you have to request one page at a time), and the point where a backend becomes the cleaner choice.

Starting with a Small First Project

If you are building your first web project, start static. HTML, CSS, and JavaScript cover a wide range of projects on their own. Deployment is straightforward (free hosting on GitHub Pages, Netlify, or Vercel, all of which serve plain files), so most of your attention can stay on the project itself. A searchable directory, an interactive timeline, a small decision tool, a documentation site with filters: all static projects. What People Build has more examples, including several from people with no prior coding experience.

A Reasonable Starting Point

Create an index.html file: the entry point of any website
Add your content: structure it with HTML, style it with CSS
Make it interactive: add JavaScript for search, filtering, or visualization
Put it on GitHub Pages: free hosting, version control built in
Iterate: add features, improve the design, get feedback

GitHub Pages, Netlify, and Vercel all host static sites for free. You upload your files (or connect a repository, a folder tracked by the version-control system Git), and the service handles delivery.

When the project starts needing user accounts, persistent shared data, or hidden credentials, you need a backend. At that point Getting Started walks through setting up Claude Code for projects at either level.