A Website, a Web App and a Local File

Why this matters

When an AI tool asks "do you want a static page or an app with state", most beginners freeze, because the words sound interchangeable. They are not, and the difference decides cost: a static page can live anywhere for free, an app with accounts and a database needs services that bill. Knowing which one you need protects you from buying infrastructure for a brochure and from promising interactivity a static page cannot deliver.

Concepts

A local file lives on your disk and opens in your browser from the disk. Double-click an HTML file and the browser renders it; no internet, no server, no other humans involved. Everything in modules M03 to M05 starts here, because local files are free, private and instant to reload.

A website is files served to visitors: someone else's browser downloads your files and renders them. The simplest site is static: the same files for everyone (menu, hours, phone number). Static sites are cheap to host and hard to break, which is why version one of almost every course project is one.

A web app is a page that remembers and reacts: it reads inputs, computes, validates and stores data in the browser (module M05) or, when truly needed, talks to a server over an API. The bakery order form that echoes entries is a small app; the same page without the form is a website. The line is behavior: does the page change based on what the visitor does?

Where things live: your files are the source of truth on your machine; the browser is the stage where they perform; a server (only when publishing, M08) is the warehouse that hands copies to visitors. Confusion usually means mixing the stage with the warehouse: editing the published copy instead of your own file, then wondering why changes vanish.

Worked example

Three versions of the bakery idea. Local file: index.html on your disk, opened by double-click, showing menu and hours to nobody but you. Website: the same file published, so neighbors read menu and hours on their phones. Web app: the published page plus an order form that checks empty fields, echoes the order and keeps entries across reloads. Same content, three levels of machinery; each level earns its keep only when the idea needs it.

Expected result: any project idea sorted into file, website or app in one sentence with the reason ("needs no storage, so website is enough").

The common wrong move

Ordering app machinery for a website job: accounts, a database and a server for a page that shows opening hours. If no visitor input is stored or shared, you need files, not infrastructure.

Lab and next step

Lab A07 opens a broken local page and sorts its failures into HTML, CSS and JavaScript causes. Next, lesson 10 names exactly what each of those three does, so the sorting becomes understanding.