Web foundations: HTTP, HTML, CSS and JavaScript

The browser side, compressed: how a request reaches a server, semantic HTML, responsive layout and the asynchronous JavaScript every full stack app depends on.

How a request reaches a server

Also called DNS, request path

What: The browser resolves the domain with DNS, opens a connection, negotiates TLS for HTTPS and sends an HTTP request. It may pass a CDN, a load balancer and a reverse proxy before your app code runs, then the response travels back the same way.
Why: When something is slow or broken, this chain tells you where to look: DNS, the proxy, your app or the database.

Watch out

Debugging app code for an error that a reverse proxy produced, such as a 502 or 504 when the app is down or too slow.

HTTP methods and status codes

Also called GET, POST, 404, 500, status code

What: Methods say what to do (GET read, POST create, PUT replace, PATCH update, DELETE remove). Status codes say what happened: 2xx success, 3xx redirect, 4xx client mistake, 5xx server failure.
Why: Clients, caches and monitoring all rely on them. Returning 200 with an error message inside hides failures from every tool.

HTTP

POST /api/posts HTTP/1.1
Content-Type: application/json

{"title": "Hello"}

HTTP/1.1 201 Created
Location: /api/posts/42

Watch out

fetch only rejects on network failure, so a 404 or 500 must be caught by checking response.ok.

Semantic HTML and forms

Also called semantic HTML

What: Use elements for their meaning (main, nav, button, a, headings in order) and give every input a label, the right type, name and autocomplete.
Why: Native elements bring keyboard support, accessibility and working forms for free. Field names are what the server receives.

HTML

<form method="post" action="/signup">
  <label for="email">Email</label>
  <input id="email" name="email" type="email"
    autocomplete="email" required>
  <button type="submit">Create account</button>
</form>

Watch out

A clickable div instead of a button, which keyboard and screen reader users cannot use.

Flexbox, Grid and responsive layout

Also called media queries, mobile first

What: Flexbox lays items out in one direction, Grid in rows and columns. Mobile first CSS writes base styles for phones and adds min-width media queries as the screen grows.
Why: Most users are on phones. These two layout tools cover nearly every admin table, form and card grid you will build.

CSS

.grid {
  display: grid;
  gap: 1rem;
  grid-template-columns:
    repeat(auto-fill, minmax(16rem, 1fr));
}

JavaScript essentials

Also called const, closures, ===

What: Use const by default and let when reassigning, compare with ===, and use ?? for defaults when 0 or "" are valid. A closure is a function that remembers the variables around it.
Why: These rules prevent the most common bugs on both sides of the stack, and closures explain callbacks, middleware and React hooks.

Watch out

Spreading an object ({ ...user }) and assuming nested objects are copied: spread is shallow.

Promises and async/await

Also called async/await, promise

What: A promise represents a value that arrives later. await pauses an async function until it settles and throws on rejection, so errors are handled with try/catch. Promise.all runs independent work in parallel.
Why: Every database call, HTTP request and file read is asynchronous, in the browser and on the server.

JavaScript

const [user, posts] = await Promise.all([
  getUser(id),
  getPostsByUser(id),
]);

Watch out

A missing await, which returns a pending promise and lets errors escape unhandled.

Event loop

Also called non-blocking I/O, microtasks, macrotasks

What: JavaScript runs one piece of code at a time. Slow work such as network and disk is handed off, and its callback is queued when done. Promise callbacks (microtasks) run before timers and I/O callbacks.
Why: It is why one Node process can serve thousands of requests, and why one CPU heavy loop freezes the page or the whole server.

Watch out

Running heavy CPU work, such as hashing a large file or a big JSON.parse, on the main thread of a busy server.

DOM, events and fetch

Also called DOM, event delegation

What: The DOM is the page as a tree of objects that scripts can read and change. Events such as click and submit bubble up to parents. fetch sends HTTP requests and returns a Response.
Why: Frameworks wrap all three, but debugging still means knowing what they do underneath.

Watch out

Inserting user text with innerHTML, which allows cross-site scripting; use textContent or framework rendering.

Go deeper