Frontend Roadmap, Tier 3: Advanced Deep Notes

This tier is where front-end stops being "make the UI" and starts being "ship it safely, fast, and maintainably at scale." The depth here is what distinguishes a senior engineer from a strong mid-level one.

---

Build Systems & Module Formats

Module Formats

Before bundlers, understand what they are bundling:

• CommonJS (CJS): require() and module.exports, the Node default historically. It is synchronous and dynamic — require can be called conditionally at runtime with a computed path. That dynamism is exactly what makes it hard to statically analyze.
• ES Modules (ESM): import and export, the standard. Imports are static: resolved at parse time, before execution, and cannot be conditional at the top level. This static structure is what enables tree-shaking.
• UMD and AMD are legacy formats you will see in older libraries but rarely author.

ESM's static, analyzable structure is the foundation everything else in this section depends on.

Bundlers

• Webpack: the long-time default, extremely configurable, large plugin ecosystem, slower builds.
• Rollup: library-focused, clean ESM output, pioneered tree-shaking.
• esbuild: written in Go, extremely fast, used as a building block by others.
• Vite: the current default for apps. In dev it serves native ESM with on-demand transforms (no bundling, near-instant startup, fast HMR), and for production it bundles with Rollup. The dev/prod split is a common interview point.

HMR (Hot Module Replacement) swaps a changed module into the running app without a full reload or losing state.

Tree-Shaking

Tree-shaking removes exports that are never imported. It relies on ESM's static structure — the bundler can prove at build time that a given export is unused.

What breaks it:

• CommonJS cannot be reliably tree-shaken. Ship and consume ESM to get tree-shaking.
• Side effects defeat it. If importing a module runs code (polyfills, global registration), the bundler cannot safely drop it. Mark side-effect-free packages with "sideEffects": false in package.json.
• Importing a whole namespace (import * as _ from "lodash") pulls everything. Import named members from ESM-friendly packages.

Code-Splitting

Code-splitting breaks the bundle into chunks loaded on demand so the initial download is only what the first view needs.

• Dynamic import() creates a split point, emitting a separate chunk loaded when that import runs.
• Route-based splitting is the highest-value default: each route is its own chunk.
• Component-level splitting (React.lazy with Suspense) defers heavy components (a chart library, a rich editor) until they are actually rendered.
• Vendor splitting separates rarely-changing third-party code into its own chunk so it stays cached across deploys.

Too few chunks means a large initial load. Too many means request overhead and waterfalls. Split along usage boundaries.

---

Security Basics

XSS (Cross-Site Scripting)

XSS is injecting attacker-controlled script that runs in the victim's page with full access to their session, cookies, and DOM. Three flavors:

• Stored: the malicious script is persisted (a comment, a profile field) and served to every viewer.
• Reflected: the script comes from the request (a URL parameter echoed into the page).
• DOM-based: entirely client-side, where untrusted data flows into a dangerous DOM sink (innerHTML, document.write, eval) without touching the server.

Defenses:

• Contextual output encoding. Escape data based on where it lands. Modern frameworks do this automatically: React escapes interpolated values by default, which is why XSS in React usually requires explicitly opting out via dangerouslySetInnerHTML.
• Sanitize HTML when you must render user-provided markup, using a vetted library like DOMPurify.
• Avoid dangerous sinks: no eval, no innerHTML from untrusted data.
• CSP as defense in depth so even if injection happens, the script will not execute.

CSRF (Cross-Site Request Forgery)

CSRF tricks an authenticated user's browser into sending a state-changing request to a site where they are logged in. It works because the browser automatically attaches cookies to requests to a domain, regardless of which site initiated them.

Defenses:

• SameSite cookies are the modern first line. SameSite=Lax (the browser default) stops cookies from being sent on cross-site subrequests, which neutralizes most CSRF automatically.
• CSRF tokens: a server-generated, unpredictable token tied to the session, sent in the form and verified server-side. An attacker cannot read or guess the token.

The key distinction: XSS is the attacker running script in your page, CSRF is the attacker making the browser send a request without script. An XSS hole defeats CSRF protection entirely (the attacker's script can read the token), so XSS is the more fundamental problem.

CSP (Content Security Policy)

CSP is a response header that whitelists where resources may load from and what may execute. script-src 'self' means only same-origin scripts run, so an injected script from an attacker domain is blocked even if injection succeeds.

Inline scripts are the hard part. Allow specific ones with a nonce (a per-response random token on both the policy and the script tag) or a hash of the script content — far safer than blanket 'unsafe-inline'. Deploy with Content-Security-Policy-Report-Only first to collect violation reports without breaking the site. CSP is defense in depth, not a substitute for output encoding.

Secure Headers

• HSTS (Strict-Transport-Security): forces HTTPS for future requests.
• X-Content-Type-Options: nosniff: stops the browser from guessing content types, which can turn an uploaded text file into executable script.
• X-Frame-Options / CSP frame-ancestors: prevents clickjacking by stopping your site from being embedded in an iframe on another origin.
• Referrer-Policy: controls how much of the referring URL is sent on navigation.
• Permissions-Policy: declares which browser features (camera, geolocation) the page may use.

Safe Handling of User Input

• Validate and authorize on the server. Client-side validation is UX, not security. The server is the only trust boundary.
• Encode at output, by context, not at input. Store raw, escape on the way out. The correct escaping depends on where it is rendered, which you do not know at input time.
• Use parameterized queries to prevent injection at the data layer.
• Least privilege everywhere: minimal cookie scope, minimal CSP allowances, minimal permissions.

---

Privacy & Permissions

Cookies

A cookie is a small key-value pair the browser stores and sends back to the setting domain. The attributes where security lives:

• HttpOnly: inaccessible to JavaScript. This is the primary defense against an XSS attacker stealing a session cookie. Auth tokens belong in HttpOnly cookies.
• Secure: only sent over HTTPS.
• SameSite: controls cross-site sending (see below).
• Domain and Path: scope which requests the cookie attaches to. Keep them narrow.

Storage

• localStorage: synchronous, persistent, strings only. Never store auth tokens or sensitive data there — an XSS hole drains it instantly. Good for non-sensitive preferences.
• sessionStorage: same API, scoped to a single tab.
• IndexedDB: asynchronous, large capacity, structured data with indexes and transactions. The real browser database.
• Cache API: stores Request/Response pairs, the storage layer behind service worker caching.

The synchronous nature of localStorage is a subtle performance point — large reads or writes block the main thread.

SameSite Rules

• Strict: cookie never sent on any cross-site request. Safest, but following a link from another site arrives logged-out.
• Lax (the modern browser default): sent on top-level navigations with safe methods, but not on cross-site subrequests (a form POST, a fetch from another origin). Blocks the classic CSRF vectors while keeping link-following logged in.
• None: sent on all cross-site requests, must be paired with Secure.

---

Offline-First Patterns

Service Workers

A service worker is a script that runs in the background on its own thread, acting as a programmable network proxy. It has no DOM access and is fully asynchronous and event-driven.

The lifecycle:

1. Register from the page.
2. Install: fires once, where you pre-cache the app shell.
3. Activate: where you clean up old caches. A new worker waits to activate until all pages controlled by the old one are gone, unless you call skipWaiting.

Caching strategies:

• Cache-first: serve from cache, fall back to network. Best for static, versioned assets.
• Network-first: try network, fall back to cache. Best for frequently changing content.
• Stale-while-revalidate: serve cache immediately, fetch in the background to update for next time. Best balance for many resources.

Service workers require HTTPS (except on localhost).

PWAs (Progressive Web Apps)

The requirements for installability:

• A web app manifest: a JSON file declaring name, icons, start_url, display mode (standalone hides browser chrome), and theme colors.
• A service worker for offline capability.
• HTTPS.

PWAs unlock installability, offline use, push notifications, background sync, and full-screen experience without an app store. The pitch is reach and update simplicity at the cost of some native API depth.

IndexedDB

IndexedDB is the browser's real client-side database: asynchronous, transactional, large-capacity, storing structured objects with indexes for querying. The right tool for offline data and caching API responses.

The honest assessment: the native API is verbose and awkward. In practice everyone uses a wrapper like idb (thin promise-based layer) or Dexie (richer ORM-like layer). Know that it is async, transactional, object-based, indexed, and that you almost always reach for a wrapper.

---

Internationalization

i18n vs l10n

• Internationalization (i18n) is the engineering work that makes an app capable of being localized: externalizing all user-facing strings, never concatenating sentence fragments, supporting locale-aware formatting. You do this once.
• Localization (l10n) is adapting the app for a specific locale: the actual translations, locale-appropriate images, currency, and cultural conventions. This happens per target market.

The cardinal i18n sin is hardcoding assumptions: concatenating "You have " + count + " items" breaks because word order, grammar, and pluralization differ by language. The fix is message formatting with placeholders — ICU MessageFormat — where the full sentence with its plural logic lives in the translation file.

Pluralization

Pluralization is harder than singular-vs-plural because languages have different numbers of plural forms. English has two. Arabic has six. Hardcoding count === 1 ? "item" : "items" is wrong for most of the world.

The correct tool is Intl.PluralRules, which maps a number to its CLDR plural category (zero, one, two, few, many, other) for a given locale. ICU MessageFormat selects the right translated string per category.

Date and Number Formats

Dates are a minefield: MM/DD/YYYY versus DD/MM/YYYY, month names, 12 versus 24 hour time, time zones, different calendar systems. Never format dates by hand. Intl.DateTimeFormat handles all of it. Store dates as UTC ISO 8601, format only at display time for the user's locale and time zone.

Numbers vary too: decimal separators (1.5 vs 1,5), thousands grouping, currency symbols. Intl.NumberFormat handles all of it, including currency (style: "currency").

Two more pieces: right-to-left (RTL) languages (Arabic, Hebrew) require the layout to mirror, handled with CSS logical properties (margin-inline-start instead of margin-left) and dir="rtl". Locale negotiation matches the user's accepted languages against your available translations. The whole Intl family is the native answer.

---

Maintainable CSS

The core problem: CSS is globally scoped with a specificity-based cascade, so at scale, styles collide, overrides pile up, and nobody can safely delete anything. Every methodology is an answer to "how do we keep this manageable."

Utility vs Component Styles

• Component styles: semantic classes named for the thing (.card, .nav-link), styling encapsulated. Markup stays clean, but you accumulate a large stylesheet.
• Utility styles: single-purpose classes (.flex, .p-4, .text-center) composed directly in markup. Final CSS is tiny because classes are reused everywhere, but the markup gets verbose.

Most teams blend them: utilities for layout and spacing, components for complex repeated patterns.

BEM

BEM (Block, Element, Modifier) is a naming convention: .block, .block__element, .block--modifier — for example .card, .card__title, .card--featured. The point is to keep specificity flat (everything is a single class) and make scope explicit through naming. It is framework-agnostic but the naming is verbose and entirely manual.

CSS-in-JS Tradeoffs

CSS-in-JS (styled-components, Emotion) writes styles in JavaScript, colocated with the component. Wins: automatic scoping, dynamic styles driven by props, dead-style elimination. Costs: runtime performance overhead, larger bundles, complications with streaming.

The important update: the field moved toward zero-runtime CSS-in-JS (vanilla-extract, Linaria, Panda CSS) that extracts styles to static CSS files at build time. The runtime-vs-build-time distinction is the whole debate.

Atomic CSS

Atomic CSS generates one class per single declaration (.mt-2 is exactly margin-top: 0.5rem). Tailwind is the popular embodiment. The production CSS is very small and stops growing — classes are shared, unused ones are purged. Deleting a component deletes its styles automatically. The criticism: verbose class lists.

The modern landscape: CSS Modules (build-time scoping), native cascade layers (@layer) that let you control the cascade explicitly, native nesting, and container queries together reduce the need for some of the old methodologies.

---

Performance

Critical Rendering Path

The Critical Rendering Path is the sequence of steps the browser must complete for first meaningful paint: parse HTML → DOM, parse CSS → CSSOM, combine into render tree, layout, paint. Optimizing it means getting to first paint with the fewest, smallest, least-blocking resources.

The blocking behaviors:

• CSS is render-blocking. The browser will not paint until it has the CSSOM. Inline critical (above-the-fold) CSS and load the rest asynchronously.
• JavaScript is parser-blocking. A plain <script> halts HTML parsing while it downloads and executes. defer (download in parallel, execute after parsing, in order) and async (download in parallel, execute as soon as ready, order not guaranteed) fix this. Use defer for app scripts, async for independent third-party scripts.

Core Web Vitals

The metrics worth memorizing:

• LCP (Largest Contentful Paint): when the largest content element renders. Target under 2.5s. Improve by preloading the LCP image with fetchpriority="high", no lazy-load, and reducing TTFB.
• INP (Interaction to Next Paint): responsiveness to user input, replaced FID. Target under 200ms. Improve by reducing long main-thread tasks and avoiding heavy work in event handlers.
• CLS (Cumulative Layout Shift): visual stability. Target under 0.1. Improve by reserving space for images, ads, and fonts.

The general levers: ship less JavaScript (biggest one for INP), code-split, optimize images, preconnect and preload critical origins, minimize main-thread work, virtualize long lists. Measure with Lighthouse for lab data and RUM (Real User Monitoring) for field data.

Paint, Layout, Compositing

• Layout (reflow): compute geometry. Most expensive, can cascade. Triggered by geometric changes.
• Paint: rasterize pixels into layers. Still main-thread work.
• Compositing: the GPU assembles layers. Cheapest — can run on the compositor thread independent of the main thread.

Properties that only affect compositing (transform, opacity) can be animated by the GPU without touching layout or paint. Properties that trigger layout (width, top, margin) recompute geometry every frame and cause jank. Promote animating elements to their own compositor layer with will-change — but layers consume memory, use it deliberately.

---

Design Systems

Building Design Systems

• Design tokens are the foundation: named values for colors, spacing, typography, radii, shadows. The mature approach layers them: primitive tokens (blue-500) hold raw values, semantic tokens (color-primary) give them meaning. This indirection lets you re-theme (dark mode, white-label) by swapping the semantic layer without touching components.
• A component library implements UI primitives (button, input, modal) with accessibility, states, and variants built in. Accessibility baked in at this layer means it is correct everywhere by default.
• Documentation (Storybook is the standard) shows every component, its props, its states, and usage guidance.

Maintaining Design Systems

The hard part is not building the system but keeping it alive and adopted — mostly an organizational problem:

• Versioning and changelogs. The system is a dependency for many teams. It needs semantic versioning, clear changelogs, codemods for breaking changes, and deprecation periods rather than abrupt removal.
• Governance and a contribution model. Decide who owns it, how teams propose changes, and how additions are reviewed for consistency.
• Adoption. Track it. Make the system the path of least resistance — easier to use than to roll your own.
• Design-to-code sync. The Figma source and coded components must not drift. Token pipelines (Style Dictionary) generate platform-specific token files from one source.

Building the components is the easy 20 percent. The durable value — and the real difficulty — is governance, versioning, and adoption: the people and process around the code.