Frontend fundamentals for designers — Localhost

This article covers the foundation of frontend codebases so you can use a coding agent effectively in one. By the end you’ll be able to clone a project, get it running on your laptop, and pair with an agent on real changes inside it.

It all runs in the browser

Every web app you use — Linear, Figma, Stripe, Notion — is loaded into a browser tab as HTML, CSS, and JavaScript. HTML is the structure, CSS is the style, JavaScript is the behavior. Frameworks, bundlers, and server rendering are different ways of producing those three things, usually with more ergonomic developer tools and faster pages.

Hold that single fact in your head — the browser is where the app actually runs — and most of the apparent complexity of modern frontend collapses.

Node

Node.js is the base of every frontend stack. It is JavaScript’s other home — instead of running inside a browser tab, Node runs on your laptop as a regular program. The frontend tools you’ll meet later in this article are all Node programs that run on top of it. You won’t run Node directly; the tools handle that for you.

The tech stack

A stack is the set of choices that turn your source code into a running web app — the language you write in, the UI library that renders components, the framework that wraps the whole thing, the styling system, and the tools that compile it all together. The layers worth recognizing are below.

Layer	What it is	Common choices
Language	The text you write code in. Compiled to JavaScript before it runs.	JavaScript or TypeScript. TypeScript adds types on top of JavaScript and compiles down automatically; the giveaway is `.ts` and `.tsx` files.
UI library	The component model — how a piece of UI is defined and re-rendered when its state changes.	React, Vue, or Svelte. You pick one; the others don’t blend.
Framework	Wraps the UI library with routing, server rendering, file conventions, image optimization, and much more.	Next.js (on React), Remix (on React), Nuxt (on Vue), SvelteKit (on Svelte), or Astro (multi-library).
CSS framework	How styles get authored.	Tailwind is by far the most common. CSS Modules and plain CSS files are the alternatives.
Package manager	Installs and manages the libraries listed in `package.json`.	npm, pnpm, or yarn. The lockfile reveals which (`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`). npm ships with Node and is the default; pnpm is faster and deduplicates better.
Bundler	Compiles your source files (TypeScript, JSX, CSS modules) into the JavaScript and CSS the browser actually runs.	Vite, webpack, Turbopack, esbuild, or swc. You rarely invoke it directly — `npm run dev` and `npm run build` do that for you.

One practical note on framework vs UI library: most frameworks come paired with their UI library, so picking the framework usually picks the UI library too — Next.js comes with React, SvelteKit with Svelte. When someone says “we use Next.js,” they mean both the framework and React.

A few common stacks

Real-world stacks combine those layers in predictable ways. A few you’ll see often:

Three real-world stacks, layer for layer. Pick a stack for a project; recognize the others when you see them.

You don’t need to memorize stacks. The choices for any project are visible in package.json and in the lockfile name — read those once and you’ll know what you’re working in.

Key files

When you open a frontend repo, the same files show up almost everywhere:

package.json — the project’s manifest. Lists the name, the libraries it depends on, and the scripts you can run (like npm run dev). Open it and read it. It’s surprisingly readable.
node_modules/ — a giant folder containing every library the project depends on, plus every library those libraries depend on, recursively. Often hundreds of megabytes. Never checked into git.
package-lock.json (or the pnpm/yarn equivalent) — a snapshot of exactly which versions of every dependency are installed. Lets a teammate or a CI server reproduce the same node_modules you have.

`npm install` reads package.json, fetches every dependency, and writes them into node_modules. After that, scripts like `npm run dev` work.

When you clone a repo for the first time and try to run it, step one is install dependencies:

npm install

This reads package.json, fetches everything it needs from npm (the registry — an App Store for code libraries), and populates node_modules. Usually 10–60 seconds. After that, the project is ready to run.

The local dev server

Here’s the moment that surprises most people new to frontend: you don’t open the HTML file in your browser directly. You start a small program — the dev server — that watches your code, compiles it, serves it to the browser, and reloads the browser whenever you save.

npm run dev

That command (or npm start, or pnpm dev, depending on the project) reads package.json, finds the dev script, and runs it. After a moment you’ll see something like:

▸ Local:   http://localhost:3000
▸ ready in 412 ms

localhost:3000 is the address of a tiny web server running on your laptop, listening on port 3000. Open that URL in any browser and you’re looking at your app.

The dev server compiles your code, serves it on localhost, and reloads the browser instantly when you save. This loop is the heartbeat of frontend development.

A couple of things make this loop feel magical:

Hot module replacement (HMR) — when you change a component file, the dev server sends just that piece to the browser, swaps it in place, and preserves your scroll position and form state. No full reload.
Source maps — when you open Chrome DevTools, you see your original source code (your beautiful TypeScript), not the compiled JavaScript the browser actually runs. Source maps are the thing that makes that work.

Try it yourself

The vocabulary above stays abstract until you actually run a project. Once you’ve done it once, the rest of this series sits on top of muscle memory.

We built a small starter for exactly this — handle-playground, a tiny Vite + React app you can clone and run in about a minute:

Install Node.js. The repo’s .nvmrc names the exact version it expects.
Clone it: git clone https://github.com/tonkotsu-ai/handle-playground.git, then cd handle-playground.
Run npm install, then npm run dev.
Open http://localhost:5173 in your browser.

That page running on your laptop is the thing you’ll change in the next two articles. When something runs locally, it stops being mysterious. From there, the next layer is the workflow every modern team uses to move code around — version control. That’s Localhost 2: Git for designers.