When you open a website, the browser requests HTML from a server. HTML is the skeleton: headings, paragraphs, forms, links, and semantic tags like `<header>`, `<main>`, `<article>`. It describes *what* is on the page, not how it looks or behaves. The browser parses this into a DOM (Document Object Model)—a tree of nodes that scripts and styles can target.

CSS (Cascading Style Sheets) describes *how* things look: colors, fonts, layout (Flexbox, Grid), spacing, and responsive breakpoints. CSS is applied to the DOM via selectors (elements, classes, IDs). One HTML file can be styled many ways (e.g. themes, print styles).

JavaScript runs in the browser and adds *behavior*: click handlers, form validation, fetching data from APIs, and updating the DOM. Together, HTML + CSS + JS are the only technologies that run directly in the browser; everything else (React, Vue, TypeScript) compiles or transpiles down to these.

Think of a building: HTML is the frame and rooms (structure). CSS is the paint, furniture, and lighting (appearance). JavaScript is the wiring and automation (lights that turn on, doors that unlock). You can have a valid, accessible page with only HTML; CSS makes it readable and beautiful; JS makes it interactive.

Separation of concerns: Keep structure (HTML), presentation (CSS), and behavior (JS) in separate files when possible. That way, designers can change styles without touching logic, and you can test or replace one layer without breaking the others. In modern frameworks (React, Vue), components often mix HTML-like markup and JS in one file, but the *concepts* of structure, style, and behavior still apply.

Front-end flow: from source to interaction

The browser does more than "display HTML." It parses HTML into a tree (the DOM), parses CSS into style rules, and combines them in a layout step (calculating size and position—the box model). Then it paints pixels to the screen. When JS changes the DOM or styles, the browser may reflow (recalculate layout) and repaint only what changed. Understanding this helps you avoid layout thrashing (reading and writing DOM in a loop) and unnecessary reflows.

Critical path: HTML and CSS block rendering until parsed; script tags can block too unless marked async/defer. The order and size of your assets (HTML, CSS, JS) directly affect First Contentful Paint and Time to Interactive. Full stack developers care because the backend often controls which assets are sent and in what order (e.g. server-rendered HTML with inline critical CSS).

User actions (click, scroll, type) and system events (load, resize) are queued as tasks. JavaScript runs in a single thread with an event loop: it processes one task at a time, then checks the queue for the next. Async work (fetch, setTimeout) is handled by the browser; when it completes, a callback is queued. So you never "block" the thread with a long operation—you register a callback and the UI stays responsive. If you do heavy computation on the main thread, the page freezes; use Web Workers for CPU-heavy work.

Why it matters for full stack: When the frontend calls your API with `fetch`, the request is sent asynchronously; the response is handled in a callback or with async/await. The same event loop handles both user events and network responses. Understanding this prevents bugs like "I set state but the UI did not update" (often a timing or closure issue) and helps you design APIs that the frontend can consume without blocking.

As a full stack developer, you will ship front-end code that talks to your backend. If you do not understand the DOM, you will not know why a form is not submitting or why an API response is not showing up. If you do not understand CSS, you will struggle with layout bugs and responsive design. If you do not understand JavaScript (events, async, fetch), you cannot build a coherent flow from UI → API → database.

Interview depth: Be able to explain: what is the DOM? What is the box model? What is event delegation? How does `fetch` work with async/await? How would you make a page accessible (semantic HTML, ARIA, keyboard nav)? These questions probe whether you can own the full stack, not just the API.

Vanilla HTML/CSS/JS: you write direct DOM manipulation (`document.getElementById`, `element.addEventListener`). No build step; simple to host. Good for small pages or when you need maximum control and minimal dependencies.

Frameworks (React, Vue, Svelte): you write components and state; the framework updates the DOM for you. You get component reuse, reactive state, and a rich ecosystem (routing, state management). The trade-off is tooling (bundler, transpiler) and learning curve. For full stack, you will usually use a framework on the front and still need to understand the underlying HTML/CSS/JS so you can debug, optimize, and integrate with the backend.

User clicks a link or submits a form → browser sends an HTTP request (GET or POST, URL, headers, optional body). The server (your backend) runs code, maybe hits a database, and returns an HTTP response (status code, headers, body—often HTML or JSON). The browser renders the new HTML (or, in a single-page app, JS fetches JSON and updates the DOM). This request–response cycle is the same whether the front is vanilla or a framework; the full stack is the path from that click to the server and back.