Frontend Roadmap, Tier 1: Beginner Deep Notes

Everything a beginner needs to understand about HTML, CSS, JavaScript, Forms, Responsive Design, and Networking — not as definitions, but as the mental models that separate someone who has used these features from someone who actually understands them.

---

HTML

Semantic HTML

Semantic HTML means choosing elements based on what the content is, not how it looks. A <button> is a button because it does button things — focusable, keyboard-activatable, announced as a button by screen readers — not because it looks clickable. A <div onclick> looks identical but is invisible to assistive tech and the keyboard.

The real reason semantics matter comes down to three audiences that read your HTML beyond the rendering engine:

1. Assistive technology. Screen readers build their navigation from the accessibility tree, which is derived from semantic elements. <nav>, <main>, <header>, <article> become landmarks a user can jump between. A page of <div>s is a flat wall with no structure to navigate.
2. The browser's built-in behavior. Semantic elements come with free behavior you would otherwise reimplement badly. <form> gives you submit-on-enter and native validation. <details> gives you a toggle with no JS. <a href> gives you middle-click-to-open-in-new-tab.
3. Search engines and other parsers. Document structure (headings hierarchy, <article>, structured data) feeds ranking and content extraction.

The interview trap: people reach for <div> and <span> by default and add roles and tabindex to patch the gaps. The right instinct is the reverse. Start from the semantic element, drop to a generic element only when nothing fits, and only then add ARIA.

Heading hierarchy is the other thing people get wrong. <h1> through <h6> describe document outline, not font size. Skipping from <h1> to <h4> because it looks right is a real accessibility bug. Style with CSS, structure with the right level.

The DOM

The DOM is the in-memory tree representation of the parsed HTML. The crucial framing: the DOM is not your HTML source, and it is not the pixels on screen. It is a live object model sitting between them.

• The HTML string is parsed once into the DOM tree.
• The DOM can then be mutated by script, and it diverges from the original source. "View source" shows the original HTML, "inspect element" shows the current DOM.
• The DOM is combined with the CSSOM (the parsed stylesheet tree) to produce the render tree, which is what actually gets laid out and painted.

Every node is an object with properties and methods. Elements, text, comments, and the document itself are all nodes. The distinction between childNodes (includes text nodes, even whitespace) and children (elements only) trips people up constantly. Whitespace between tags in your HTML becomes real text nodes in the DOM.

DOM access is comparatively slow because reading certain properties (offsetHeight, getBoundingClientRect) forces the browser to compute layout. This is the seed of layout thrashing: touching the DOM can be cheap (changing a property) or expensive (forcing a recalculation), and batching reads separately from writes is how you keep it cheap.

---

CSS Fundamentals

Cascade

The cascade is the algorithm that decides which value wins when multiple rules target the same element and property. It resolves conflicts in this order:

1. Origin and importance. Author styles normally beat user-agent (browser default) styles. But !important flips the layers, and user !important styles beat author !important styles. The full order from weakest to strongest: user-agent normal, user normal, author normal, author important, user important, user-agent important.
2. Specificity. Within the same origin and importance, the more specific selector wins.
3. Source order. If specificity ties, the rule declared later in the source wins.

The cascade is why load order of stylesheets matters and why a utility class can lose to a more specific selector even when it appears later. People reach for !important when they lose a cascade fight they do not understand. Knowing the order means you can win it with a cleaner selector instead.

Specificity

Specificity is scored as a tuple, commonly written (a, b, c):

• a = number of ID selectors
• b = number of class, attribute, and pseudo-class selectors
• c = number of type (element) and pseudo-element selectors

Inline styles sit above all of these. !important sits above even inline. Compare tuples left to right: a single ID beats any number of classes, a single class beats any number of elements.

The non-obvious rules that get asked:

• The universal selector * and combinators (>, +, ~, descendant space) contribute nothing to specificity.
• :not() and :is() add nothing themselves, but take the specificity of their most specific argument. So :not(#id) counts as one ID.
• :where() always has zero specificity no matter what is inside it — the modern escape hatch for writing low-specificity defaults that are trivially overridden.

Keep specificity flat and low. High specificity is a debt. When everything is one class deep, the cascade becomes predictable and source order does the work.

Box Model

Every element is a box made of four concentric areas: content, padding, border, margin. The model that matters is how width is interpreted, controlled by box-sizing:

• content-box (the default): width sets the content area only. Padding and border are added on top, so a width: 200px element with 20px padding and a 2px border is actually 244px wide.
• border-box: width includes padding and border. A width: 200px border-box element is 200px wide, full stop, with padding eating into the content space.

Almost every codebase sets box-sizing: border-box globally because predictable sizing is worth it. Margin is always outside the box and never counted in either model.

Margin collapsing is the other classic gotcha. Vertical margins between adjacent block elements collapse to the larger of the two rather than summing. This only happens vertically, only between block-level boxes in normal flow, and is prevented by padding, borders, or a different formatting context (flex and grid children do not collapse).

Flexbox

Flexbox is one-dimensional layout. You lay items along a single axis (a row or a column) and control how they distribute space along that axis and align across it.

The two axes:

• Main axis: set by flex-direction (row by default, or column). justify-content distributes items along it.
• Cross axis: perpendicular to main. align-items aligns items across it, align-content handles multiple wrapped lines.

The flex shorthand is where understanding shows. flex: 1 expands to flex: 1 1 0%, meaning flex-grow: 1, flex-shrink: 1, flex-basis: 0%. The difference between flex: 1 and flex: auto (1 1 auto) is whether the item's intrinsic content size is the starting point. With basis 0, all items share space proportionally regardless of content. With basis auto, content size is respected first and only leftover space is distributed.

flex-shrink is the one people forget. By default items can shrink below their basis. Setting flex-shrink: 0 or min-width: 0 (flex items have an implicit min-width: auto that prevents shrinking below content size) solves a whole class of overflow bugs.

Grid

Grid is two-dimensional layout. You define rows and columns explicitly and place items into the resulting cells.

Core pieces:

• grid-template-columns and grid-template-rows define the tracks. The fr unit represents a fraction of available space, so 1fr 2fr splits remaining space one-to-two.
• gap sets gutters between tracks.
• minmax(min, max) lets a track flex between bounds. minmax(200px, 1fr) means "at least 200px, grow to fill."
• repeat(auto-fill, minmax(200px, 1fr)) creates as many tracks as fit, leaving empty tracks. auto-fit collapses empty tracks to zero, letting remaining items stretch to fill the row. Use auto-fit when you want items to grow to fill, auto-fill when you want a stable grid.

Implicit vs explicit grid: tracks you define are explicit. When you place more items than defined cells, the browser creates implicit tracks, sized by grid-auto-rows / grid-auto-columns.

The mental split: grid for the overall page or component skeleton (two-dimensional), flexbox for the contents of a region (one-dimensional). They compose — a grid cell often contains a flex container.

---

JavaScript

Data Types

JavaScript has seven primitives (string, number, bigint, boolean, undefined, symbol, null) and one composite type, object (which includes arrays, functions, dates — everything non-primitive).

The points that matter:

• Primitives are immutable and copied by value. Objects are referenced — copying a variable copies the reference, and two variables can point at the same object.
• typeof null returns "object". A famous bug that can never be fixed without breaking the web. Memorize it.
• NaN is a number and is not equal to itself. NaN === NaN is false. Use Number.isNaN() to test for it.
• undefined vs null. undefined means a value was never assigned. null is an intentional "no value." The language produces undefined on its own (missing properties, no return value), you produce null deliberately.
• Equality. == does type coercion with surprising rules, === does not. Default to ===.

Timeouts and the Event Loop

setTimeout and setInterval schedule work for later, but understanding them requires the event loop.

JavaScript runs on a single thread with a call stack. When the stack is empty, the event loop pulls the next task from a queue and runs it to completion. Two queue types with a critical ordering rule:

• Macrotasks: setTimeout, setInterval, I/O, UI events. One macrotask runs per loop iteration.
• Microtasks: promise callbacks (.then, await continuations), queueMicrotask, MutationObserver. The entire microtask queue drains after each macrotask and before the next, and before rendering.

This is why this logs 1, 4, 3, 2:

JSfile.js
1console.log(1);
2setTimeout(() => console.log(2), 0);
3Promise.resolve().then(() => console.log(3));
4console.log(4);

The synchronous code runs first (1, 4), then all microtasks drain (3), then the macrotask (2).

setTimeout(fn, 0) does not run immediately. The HTML spec clamps nested timeouts to a minimum around 4ms, and the callback only runs once the stack is clear. "0" means "as soon as possible after current work, behind any pending microtasks."

Promises

A Promise is an object representing the eventual result of an async operation. It is in one of three states: pending, then either fulfilled (with a value) or rejected (with a reason). Once settled it never changes.

.then returns a new promise, so you chain. Whatever you return from a .then becomes the fulfillment value of the next one. One .catch at the end of a chain catches errors from any step above it. .finally runs regardless of outcome and passes the value or error through untouched.

Things people miss:

• Promise executors run synchronously. The function you pass to new Promise((resolve) => ...) runs immediately — only the callbacks are async.
• .then callbacks always run as microtasks, never synchronously, even if the promise is already resolved.
• A promise with no .catch that rejects produces an unhandled rejection warning.

Async/Await

async/await is syntactic sugar over promises. An async function always returns a promise. await pauses the function until the awaited promise settles, then resumes with the value, or throws if it rejected.

await does not block the thread. It suspends the function and returns control to the event loop. When the awaited promise settles, the continuation is scheduled as a microtask.

The single most common performance mistake is awaiting in a loop when the operations are independent:

JSfile.js
1// Sequential, slow — each await waits for the previous
2for (const id of ids) {
3  results.push(await fetchUser(id));
4}
5
6// Parallel, fast — all requests fire, then we wait once
7const results = await Promise.all(ids.map(fetchUser));

Sequential await is correct when each step depends on the previous one. When they are independent, you are leaving concurrency on the table.

---

Forms

Without JavaScript

A plain <form> with the right markup gives you, for free: submit on Enter, a submit event, native validation, and accessible labels.

The non-negotiables:

• Every input needs an associated <label>, either wrapping it or linked by for/id.
• Use the right type (email, tel, url, number, date). On mobile this changes the keyboard, and types come with built-in validation.
• Native validation attributes (required, min, max, pattern, minlength) trigger browser validation and the :invalid / :valid pseudo-classes — no script needed.
• name attributes matter because they become the keys when the form serializes. No name, no submission for that field.

A form that posts to a server with correct markup works with JavaScript disabled, degrades gracefully, and is accessible by default. That is the baseline you enhance from.

With JavaScript

You add JavaScript to a form for richer behavior: client-side validation with custom messaging, async submission without a page reload, dynamic fields.

Key APIs and patterns:

• event.preventDefault() on the submit event stops the native navigation so you can handle it yourself with fetch.
• FormData reads all named fields at once: new FormData(formElement). It handles file inputs and multipart encoding for you.
• The Constraint Validation API (checkValidity(), setCustomValidity(), validity object) lets you hook into native validation rather than reinventing it.
• Controlled vs uncontrolled (in React terms): a controlled input has its value driven by state, an uncontrolled one keeps its own value in the DOM and you read it on submit.

Enhance the native form, do not replace it. Keep the markup semantic so it still works if your script fails to load, and let the browser do the parts it already does well.

---

Responsive Design

CSS Media Queries

Media queries apply styles conditionally based on the viewport. The strategy is mobile-first — write base styles for the smallest screen, then layer enhancements with min-width queries as the viewport grows.

This is better than desktop-first (max-width) because base styles are the simplest case, additions are additive rather than overrides, and mobile devices (often the weakest hardware) load the least CSS.

Beyond width, media queries can test:

• prefers-color-scheme — dark mode
• prefers-reduced-motion — accessibility; always respect it
• hover and pointer — distinguish touch from mouse

The modern shift: a lot of what needed media queries is now better done without them. clamp() for fluid type, minmax() with auto-fit in grid, and flexbox wrapping adapt continuously. Container queries (@container) let a component respond to its own container's size — the right tool for reusable components that live in different-width slots. Breakpoints are still useful for page-level layout shifts, but they are no longer the only tool.

---

Networking

HTTP

HTTP is the request/response protocol of the web. A client sends a request (method, path, headers, optional body), the server returns a response (status code, headers, optional body).

Methods carry semantics. GET reads and should be safe and idempotent (no side effects, repeatable). POST creates or triggers actions. PUT replaces idempotently, PATCH partially updates, DELETE removes. Idempotency determines what is safe to retry.

Status codes by class: 2xx success, 3xx redirection (301 permanent, 302/307 temporary, 304 not modified), 4xx client error (400 bad request, 401 unauthenticated, 403 forbidden, 404 not found, 429 rate limited), 5xx server error.

Statelessness. HTTP itself remembers nothing between requests. State is reconstructed each time via cookies, tokens, or server sessions.

Caching

HTTP caching avoids refetching resources that have not changed. Controlled by response headers at two levels: freshness and validation.

• Cache-Control: max-age=N sets freshness lifetime in seconds. no-cache means cache it but always revalidate (not "do not cache"). no-store means never cache. private allows browser caching but not CDN. immutable promises the resource never changes during its lifetime. stale-while-revalidate serves a stale copy immediately while refreshing in the background.
• Validation: The server sends an ETag (content fingerprint) or Last-Modified date. On the next request the browser sends If-None-Match or If-Modified-Since. If unchanged, the server responds 304 Not Modified with no body.

max-age saves the entire round trip — the browser does not even ask. Validation saves only the body transfer, you still pay one round trip. For assets you want maximum performance on, you want long max-age, which leads to the cache busting strategies below.

CDNs

A Content Delivery Network is a geographically distributed set of edge servers that cache your content close to users. Physics caps how fast data crosses the planet, so serving a user in Delhi from a Mumbai edge instead of a Virginia origin removes most of the round-trip time.

What a CDN buys you beyond raw distance:

• Reduced origin load. Cached responses are served from the edge.
• Origin shielding. A mid-tier cache layer absorbs misses so a stampede of edge misses does not all hit the origin at once.
• TLS termination and connection reuse at the edge.

A CDN is just a cache with the same freshness and validation rules as the browser, applied at the network edge. Your Cache-Control headers (public and s-maxage) control its behavior.

HTTP/2

HTTP/1.1 had a structural problem: a connection could carry one request at a time, so browsers opened six parallel connections per origin and still hit head-of-line blocking, where a slow response stalled everything behind it.

HTTP/2 fixes this with:

• Multiplexing over a single connection. Many requests and responses interleave as independent streams. No more six-connection limit.
• Binary framing. More efficient to parse, enables multiplexing.
• Header compression (HPACK). Repeated headers (cookies, user-agent) across requests are compressed.

The catch: HTTP/2 still rides on TCP, so a lost packet stalls all streams at the transport layer. HTTP/3 moves to QUIC over UDP to solve exactly that, making each stream independent end to end. HTTP/2 fixed the application layer; HTTP/3 fixed the transport layer — that is the senior-level answer.

Latency Mitigation

Latency is round-trip time, and it is the enemy that bandwidth cannot fix. The strategies cluster into two ideas:

Cut the number of round trips. Fewer requests, bundled critical resources, HTTP/2 multiplexing, connection reuse. Resource hints: dns-prefetch resolves DNS early, preconnect opens TCP and TLS early, preload fetches critical resources before the parser discovers them, prefetch grabs likely-next-navigation resources during idle time.

Send fewer bytes. Compression (Brotli over gzip where supported), responsive images, code splitting so the initial payload is small.

The framing that helps: separate "make the network faster" (CDN, HTTP/2, compression) from "need the network less" (caching, prefetching, smaller payloads). Most real wins come from the second category.

Cache Invalidation

The tension is real: long cache lifetimes are fast, but then how do you ship an update?

Content hashing (cache busting) — the industry default. Name files by a hash of their contents: app.4f8a2c.js. When content changes, the filename changes — it is a new URL the cache has never seen. The old file stays cached forever with max-age of a year plus immutable, because it will never be requested again. The HTML that references hashed files is served with a short or no-cache policy so new filenames are picked up promptly.

Versioned URLs / query strings. app.js?v=2. Simpler, but query-string caching is less reliable across some intermediary caches. Hashed filenames are preferred.

Validation-based (ETag / Last-Modified). Accept a round trip on every request in exchange for always serving fresh content with 304s when unchanged. Good for content that changes unpredictably.

Active purging. Explicitly tell the CDN to evict a resource. Necessary for content you cannot rename (a fixed API endpoint, an HTML entry point) that must update immediately.

The unifying principle: the cheapest invalidation is the one you never perform. The industry settled on hashed immutable assets plus a short-lived HTML shell — you almost never invalidate anything, you just change the name.