Your Workbench

Everything in this book needs two programs: an editor to write the files and a browser to see them. This page sets both up once, together with one small addition that saves hours later: a preview server that shows your page the way a real website would, and reloads it each time you save.

Think of a workshop. The editor is the bench where the work happens, the browser is the mirror that shows the result, and the preview server is an assistant who holds the mirror up every time you put the tool down.

Why Not Use a Word Processor?

Web pages are plain text: letters, numbers and punctuation, nothing else. A word processor such as Word or Pages saves much more than the letters you see. It stores fonts, margins and page settings inside the file, in its own format, and a browser cannot read that as HTML. Even if you save as plain text, a word processor has usually swapped your straight quotes for curly ones as you typed, which breaks code in ways that are hard to spot.

A code editor saves exactly the characters you type and nothing else, and it helps while you type: it colours different parts of the code, indents lines for you and closes tags you open. This book uses Visual Studio Code, usually called VS Code: it is free, it runs on Windows, macOS and Linux, and it is the most widely used editor for web work. Any editor that saves plain text and can open a whole folder will do, but the instructions here follow VS Code.

Install it from its official site, code.visualstudio.com. On Windows, run the installer and accept the defaults. On macOS, open the downloaded file and drag Visual Studio Code into your Applications folder. On Linux, the site lists the package for your system, and everything else in this book works the same way there.

One habit matters from the start: in VS Code you open a folder, not a single file. Use File, then Open Folder. The editor then shows every file in that folder in a side panel, and that folder is your project. From the next topic on, it will be your site.

What Is a Preview Server, and Why Do You Want One?

You can open an HTML file by double-clicking it, and the browser will show it. The address bar then starts with file://, which means the browser is reading the file straight from your disk. For a plain page that works. For two things later in the book, it does not: JavaScript files that load each other as modules, in Chapter 7, and loading data from a file in Chapter 11. Browsers block both for pages opened that way, for security reasons Chapter 11 explains.

A local server fixes this. It is a small program on your own computer that answers the browser the same way a real web server would, so the address starts with http:// instead of file://, and everything behaves as it will once the site is published.

In VS Code, the local server comes as an extension, an add-on you install from inside the editor. Open the Extensions view from the icon of four squares on the left side, or with Ctrl+Shift+X on Windows and Cmd+Shift+X on macOS. Search for Live Preview, check that the publisher is Microsoft, and select Install.

Once it is installed, an HTML file open in the editor shows a preview button in the top right corner of the editor. Selecting it opens the page in a panel next to your code, served from a local address that starts with http://127.0.0.1. That address also works in your real browser: copy it from the preview panel's address bar and paste it into a browser tab.

One setting is worth changing now. By default, Live Preview updates the page as you type, before you save. That feels convenient, but it hides the difference between the file on disk and the text in the editor, which is the difference that matters when the site is published. In VS Code's settings, search for Live Preview auto refresh, and set the setting called Auto Refresh Preview to On Changes to Saved Files. From then on, the preview changes only when you save.

Which Browser Should You Use?

Any current version of Chrome, Firefox or Safari. Every browser has built-in developer tools, usually called DevTools, a set of panels for looking inside a page, which Chapter 2 introduces. This book's instructions follow Chrome's DevTools, because it is the most widely used and Edge shares the same one. Firefox and Safari have the same panels under similar names. As the previous topic explained, it is worth opening your finished pages in a browser from each of the three engines at least once.

Which Habits Prevent Strange Bugs?

A few habits with files prevent a whole family of problems that look mysterious to a beginner and are trivial once you know them.

Show file extensions. Windows and macOS hide the part of a file name after the dot by default, so a file you named index.html can secretly be index.html.txt. On Windows 11, open File Explorer, then View, then Show, and turn on file name extensions; on Windows 10 the same checkbox is on File Explorer's View tab. On macOS, open Finder's settings, then Advanced, and turn on the option to show all filename extensions.

Name files in lowercase, without spaces. Use about-me.html, not About Me.html. Spaces turn into awkward codes in web addresses, and many web servers treat About.html and about.html as different files, even though your own computer may not. A link that works on your machine and breaks once published is very often a capital letter.

One folder per site. Keep every file of a site inside its own folder, and never save work as "Untitled". Chapter 2 shows how files find each other by their position in that folder.

What Does This Book Leave Out?

No Node, no npm, no terminal, no build step. You will see those names everywhere in tutorials and job listings, and professional projects often use them. They solve real problems, but problems that appear when a project gets large, and they sit on top of exactly what this book teaches. Chapter 13 explains what each of them does and when a project needs it. Until then, an editor and a browser are the whole toolkit.