Every article is filed under one of 200 categories. 235 pieces so far.
What actually happens between a keystroke in the address bar and pixels on the screen — the layer every frontend bug eventually bottoms out in.
The document itself. Get this layer right and accessibility, SEO, and progressive enhancement mostly come for free.
Layout, spacing, and visual state. Most CSS pain is a layout-model misunderstanding rather than a missing property.
The language and its runtime model. Frameworks come and go; closures, the event loop, and modules do not.
Browser capabilities you reach for directly, before adding a dependency that wraps the same thing.
Git plus the hosting platform your team actually works in — branches, review, and CI as one workflow.
Installing, pinning, and auditing dependencies — and why the lockfile is the file that matters.
Component models, reactivity, and routing. Learn one properly; the second one takes a weekend.
Making components composable rather than configurable. These are the patterns that stop a component from growing a wall of boolean props.
Deciding where a value lives. Most state management problems are really one value stored in the wrong place.
The agreement between your UI and the server. GraphQL is one answer to this; these are the others.
Server state is not application state. It is a cache of someone else’s data, and it goes stale while you hold it.
A typed query layer between the client and its data — and the caching problem it moves rather than removes.
Scaling CSS past one person: conventions, utilities, tokens, and the components everyone reuses.
Motion that explains a change rather than decorating it — and stays cheap enough to hold a steady frame rate.
Usually the largest bytes on the page, and the performance win nobody gets round to collecting.
Building for more than one language, script, and calendar. Cheap to design in, expensive to retrofit.
Everything between the source you write and the bytes you ship: linting, formatting, bundling, transpiling.
One repository, many packages. The tooling exists to make the build fast enough that the arrangement pays off.
Confidence per second of CI. Pick the cheapest test that would actually have caught the bug.
Catching a class of bug before the browser ever runs the code — and knowing where types stop helping.
The attacks a frontend is actually responsible for, and the browser primitives that mitigate them.
The platform’s own component model — useful precisely where a framework cannot reach.
Splitting one UI across independently deployed teams. An organisational solution with real technical costs — worth knowing before you need it, and before you reach for it.
Rendering on the server for first paint and SEO, then hydrating — and the whole class of bugs that creates.
Installability, offline behaviour, and background work — web apps that survive a bad connection.
Measure, then fix. Almost every real win is fewer bytes, fewer round trips, or less main-thread work.
Knowing the app broke for a user who never filed a ticket — and having enough context to fix it.
Shipping behind a flag, measuring what happened, and being honest with yourself about the result.
Rendering at build time. The fastest page is one that was finished before the request arrived.
Shipping the same skills outside a browser tab — and the platform constraints that come with it.
Getting the build in front of users: previews, rollbacks, environments, and the edge.
Using models to write and review frontend code — what the workflow changes, and what it does not.
The editors and agents in the loop. Learn one well — the others are variations on the same shape.
Shipping model-backed UI: streaming, tool calls, and the loading and error states nobody designs first.