diff --git a/README.md b/README.md
index 69c7066..1cd39a9 100644
--- a/README.md
+++ b/README.md
@@ -53,7 +53,7 @@ This list contains the top essential questions that are frequently-asked during
 | 21 | [Describe event bubbling in JavaScript and browsers](#describe-event-bubbling-in-javascript-and-browsers) | Basic |
 | 22 | [Describe event capturing in JavaScript and browsers](#describe-event-capturing-in-javascript-and-browsers) | Basic |
 | 23 | [What is the difference between `mouseenter` and `mouseover` event in JavaScript and browsers?](#what-is-the-difference-between-mouseenter-and-mouseover-event-in-javascript-and-browsers) | Basic |
-| 24 | [What is `'use strict';` in JavaScript for?](#what-is-use-strict-in-javascript-for) | Advanced |
+| 24 | [What is `'use strict';` (strict mode) in JavaScript for?](#what-is-use-strict-strict-mode-in-javascript-for) | Advanced |
 | 25 | [Explain the difference between synchronous and asynchronous functions in JavaScript](#explain-the-difference-between-synchronous-and-asynchronous-functions-in-javascript) | Basic |
 | 26 | [What are the pros and cons of using Promises instead of callbacks in JavaScript?](#what-are-the-pros-and-cons-of-using-promises-instead-of-callbacks-in-javascript) | Intermediate |
 | 27 | [Explain AJAX in as much detail as possible](#explain-ajax-in-as-much-detail-as-possible) | Basic |
@@ -276,13 +276,13 @@ This list contains a longer list of important JavaScript questions. Not all of t
 | 183 | [What are some tools and techniques for identifying security vulnerabilities in JavaScript code?](#what-are-some-tools-and-techniques-for-identifying-security-vulnerabilities-in-javascript-code) | Intermediate |
 | 184 | [How can you implement secure authentication and authorization in JavaScript applications?](#how-can-you-implement-secure-authentication-and-authorization-in-javascript-applications) | Advanced |
 | 185 | [Explain the same-origin policy with regards to JavaScript](#explain-the-same-origin-policy-with-regards-to-javascript) | Intermediate |
-| 186 | [What is `'use strict';` in JavaScript for?](#what-is-use-strict-in-javascript-for) | Advanced |
+| 186 | [What is `'use strict';` (strict mode) in JavaScript for?](#what-is-use-strict-strict-mode-in-javascript-for) | Advanced |
 | 187 | [What tools and techniques do you use for debugging JavaScript code?](#what-tools-and-techniques-do-you-use-for-debugging-javascript-code) | Intermediate |
 | 188 | [How does JavaScript garbage collection work?](#how-does-javascript-garbage-collection-work) | Advanced |
 | 189 | [Explain what a single page app is and how to make one SEO-friendly](#explain-what-a-single-page-app-is-and-how-to-make-one-seo-friendly) | Intermediate |
 | 190 | [How can you share code between JavaScript files?](#how-can-you-share-code-between-javascript-files) | Basic |
 | 191 | [How do you organize your code?](#how-do-you-organize-your-code) | Intermediate |
-| 192 | [What are some of the advantages/disadvantages of writing JavaScript code in a language that compiles to JavaScript?](#what-are-some-of-the-advantagesdisadvantages-of-writing-javascript-code-in-a-language-that-compiles-to-javascript) | Advanced |
+| 192 | [What are some of the advantages and disadvantages of using TypeScript and compile-to-JavaScript languages](#what-are-some-of-the-advantages-and-disadvantages-of-using-typescript-and-compile-to-javascript-languages) | Advanced |
 | 193 | [When would you use `document.write()`?](#when-would-you-use-documentwrite) | Advanced |
 
 <!-- TABLE_OF_CONTENTS:ALL:END -->
@@ -497,13 +497,13 @@ All of these ways (`<script>`, `<script async>`, and `<script defer>`) are used
 - `<script async>` downloads the script asynchronously, in parallel with parsing the HTML. Executes the script as soon as it is available, potentially interrupting the HTML parsing. Multiple `<script async>` tags do not wait for each other and execute in no particular order.
 - `<script defer>` downloads the script asynchronously, in parallel with parsing the HTML. However, the execution of the script is deferred until HTML parsing is complete, in the order they appear in the HTML.
 
-Here's a table summarizing the 3 ways of loading `<script>`s in an HTML document.
+Here's a table summarizing the 4 ways of loading `<script>`s in an HTML document. Modern apps almost always use modules, which deserve their own row.
 
-| Feature | `<script>` | `<script async>` | `<script defer>` |
-| --- | --- | --- | --- |
-| Parsing behavior | Blocks HTML parsing | Runs parallel to parsing | Runs parallel to parsing |
-| Execution order | In order of appearance | Not guaranteed | In order of appearance |
-| DOM dependency | No | No | Yes (waits for DOM) |
+| Feature | `<script>` | `<script async>` | `<script defer>` | `<script type="module">` |
+| --- | --- | --- | --- | --- |
+| Parsing behavior | Blocks HTML parsing | Downloads in parallel; execution still blocks parsing | Downloads in parallel; execution deferred until after parsing | Downloads in parallel; execution deferred until after parsing |
+| Execution order | In order of appearance | Not guaranteed | In order of appearance | In order of appearance, with each script's `import` dependencies resolved first |
+| DOM dependency | No | No | Yes (waits for DOM) | Yes (waits for DOM) |
 
 <!-- Update here: /questions/describe-the-difference-between-script-async-and-script-defer/en-US.mdx -->
 
@@ -1077,7 +1077,7 @@ The main difference lies in the bubbling behavior of `mouseenter` and `mouseover
 
 <br>
 
-### What is `'use strict';` in JavaScript for?
+### What is `'use strict';` (strict mode) in JavaScript for?
 
 <!-- Update here: /questions/what-is-use-strict-what-are-the-advantages-and-disadvantages-to-using-it/en-US.mdx -->
 
@@ -4982,13 +4982,13 @@ All of these ways (`<script>`, `<script async>`, and `<script defer>`) are used
 - `<script async>` downloads the script asynchronously, in parallel with parsing the HTML. Executes the script as soon as it is available, potentially interrupting the HTML parsing. Multiple `<script async>` tags do not wait for each other and execute in no particular order.
 - `<script defer>` downloads the script asynchronously, in parallel with parsing the HTML. However, the execution of the script is deferred until HTML parsing is complete, in the order they appear in the HTML.
 
-Here's a table summarizing the 3 ways of loading `<script>`s in an HTML document.
+Here's a table summarizing the 4 ways of loading `<script>`s in an HTML document. Modern apps almost always use modules, which deserve their own row.
 
-| Feature | `<script>` | `<script async>` | `<script defer>` |
-| --- | --- | --- | --- |
-| Parsing behavior | Blocks HTML parsing | Runs parallel to parsing | Runs parallel to parsing |
-| Execution order | In order of appearance | Not guaranteed | In order of appearance |
-| DOM dependency | No | No | Yes (waits for DOM) |
+| Feature | `<script>` | `<script async>` | `<script defer>` | `<script type="module">` |
+| --- | --- | --- | --- | --- |
+| Parsing behavior | Blocks HTML parsing | Downloads in parallel; execution still blocks parsing | Downloads in parallel; execution deferred until after parsing | Downloads in parallel; execution deferred until after parsing |
+| Execution order | In order of appearance | Not guaranteed | In order of appearance | In order of appearance, with each script's `import` dependencies resolved first |
+| DOM dependency | No | No | Yes (waits for DOM) | Yes (waits for DOM) |
 
 <!-- Update here: /questions/describe-the-difference-between-script-async-and-script-defer/en-US.mdx -->
 
@@ -6979,7 +6979,7 @@ The same-origin policy is a security measure implemented in web browsers to prev
 
 <br>
 
-### What is `'use strict';` in JavaScript for?
+### What is `'use strict';` (strict mode) in JavaScript for?
 
 <!-- Update here: /questions/what-is-use-strict-what-are-the-advantages-and-disadvantages-to-using-it/en-US.mdx -->
 
@@ -7140,11 +7140,11 @@ I organize my code by following a modular approach, using a clear folder structu
 
 <br>
 
-### What are some of the advantages/disadvantages of writing JavaScript code in a language that compiles to JavaScript?
+### What are some of the advantages and disadvantages of using TypeScript and compile-to-JavaScript languages
 
 <!-- Update here: /questions/what-are-some-of-the-advantages-disadvantages-of-writing-javascript-code-in-a-language-that-compiles-to-javascript/en-US.mdx -->
 
-Using languages that compile to JavaScript, like TypeScript or CoffeeScript, can offer several advantages such as improved syntax, type safety, and better tooling. However, they also come with disadvantages like added build steps, potential performance overhead, and the need to learn new syntax.
+Using languages that compile to JavaScript (most commonly TypeScript today, but historically also CoffeeScript, ReScript, Elm, and ClojureScript) can offer several advantages such as improved syntax, type safety, and better tooling. However, they also come with disadvantages like added build steps, potential performance overhead, and the need to learn new syntax.
 
 Advantages:
 
@@ -7377,7 +7377,7 @@ JavaScript interview questions categorized by difficulty.
 
 <!-- QUESTIONS:ADVANCED:START -->
 
-1. [What is `'use strict';` in JavaScript for?](#what-is-use-strict-in-javascript-for)
+1. [What is `'use strict';` (strict mode) in JavaScript for?](#what-is-use-strict-strict-mode-in-javascript-for)
 2. [What are JavaScript polyfills for?](#what-are-javascript-polyfills-for)
 3. [What are iterators and generators in JavaScript and what are they used for?](#what-are-iterators-and-generators-in-javascript-and-what-are-they-used-for)
 4. [What are server-sent events?](#what-are-server-sent-events)
@@ -7393,7 +7393,7 @@ JavaScript interview questions categorized by difficulty.
 14. [How do you validate form elements using the Constraint Validation API?](#how-do-you-validate-form-elements-using-the-constraint-validation-api)
 15. [How does hoisting affect function declarations and expressions?](#how-does-hoisting-affect-function-declarations-and-expressions)
 16. [What are mocks and stubs and how are they used in testing?](#what-are-mocks-and-stubs-and-how-are-they-used-in-testing)
-17. [What are some of the advantages/disadvantages of writing JavaScript code in a language that compiles to JavaScript?](#what-are-some-of-the-advantagesdisadvantages-of-writing-javascript-code-in-a-language-that-compiles-to-javascript)
+17. [What are some of the advantages and disadvantages of using TypeScript and compile-to-JavaScript languages](#what-are-some-of-the-advantages-and-disadvantages-of-using-typescript-and-compile-to-javascript-languages)
 18. [What are some techniques for reducing reflows and repaints?](#what-are-some-techniques-for-reducing-reflows-and-repaints)
 19. [What are some tools that can be used to measure and analyze JavaScript performance?](#what-are-some-tools-that-can-be-used-to-measure-and-analyze-javascript-performance)
 20. [What are Web Workers and how can they be used to improve performance?](#what-are-web-workers-and-how-can-they-be-used-to-improve-performance)
diff --git a/questions/describe-event-capturing/en-US.mdx b/questions/describe-event-capturing/en-US.mdx
index 1ea41d5..afd9fcb 100644
--- a/questions/describe-event-capturing/en-US.mdx
+++ b/questions/describe-event-capturing/en-US.mdx
@@ -81,13 +81,105 @@ child.addEventListener('click', () => {
 
 As a result of stopping event propagation, only the `parent` event listener will be called when you click the "Click me!" button, and the `child` event listener will never be called because event propagation has stopped at the `parent` element.
 
-## Uses of event capturing
+## Predict the output: capture, target, bubble in order
 
-Event capturing is rarely used as compared to event bubbling, but it can be used in specific scenarios where you need to intercept events at a higher level before they reach the target element.
+The complete event flow is the part candidates most often get wrong. The same `click` event passes through every ancestor on the way down (capture), arrives at the target, then walks back up (bubble). Here is the full sequence in one runnable example:
 
-- **Stopping event bubbling:** Imagine you have a nested element (like a button) inside a container element. Clicking the button might also trigger a click event on the container. By enabling event capturing on the container's event listener, you can capture the click event there and prevent it from traveling down to the button, potentially causing unintended behavior.
-- **Custom dropdown menus:** When building custom dropdown menus, you might want to capture clicks outside the menu element to close the menu. Using `capture: true` on the `document` object allows you to listen for clicks anywhere on the page and close the menu if the click happens outside its boundaries.
-- **Efficiency in certain scenarios:** In some situations, event capturing can be slightly more efficient than relying on bubbling. This is because the event doesn't need to propagate through all child elements before reaching the handler. However, the performance difference is usually negligible for most web applications.
+```js live
+const grandparent = document.createElement('div');
+const parent = document.createElement('div');
+const child = document.createElement('button');
+grandparent.appendChild(parent);
+parent.appendChild(child);
+document.body.appendChild(grandparent);
+
+// Capture handlers (third arg = true)
+grandparent.addEventListener(
+  'click',
+  () => console.log('1. grandparent capture'),
+  true,
+);
+parent.addEventListener('click', () => console.log('2. parent capture'), true);
+
+// Target handler (default: bubble phase)
+child.addEventListener('click', () => console.log('3. target'));
+
+// Bubble handlers
+parent.addEventListener('click', () => console.log('4. parent bubble'));
+grandparent.addEventListener('click', () =>
+  console.log('5. grandparent bubble'),
+);
+
+child.click();
+// Output (in this exact order):
+// 1. grandparent capture
+// 2. parent capture
+// 3. target
+// 4. parent bubble
+// 5. grandparent bubble
+```
+
+The full picture: events go down, then up. Capture handlers fire from the root toward the target; bubble handlers fire from the target back toward the root. The target's own handler runs in the middle. (Listeners on the target itself fire in registration order regardless of the `capture` argument; the capture/bubble distinction only applies to ancestors.)
+
+## Bubbling vs capturing comparison
+
+|  | Capturing | Bubbling |
+| --- | --- | --- |
+| Phase order | First (down from root) | Last (up to root) |
+| `useCapture` argument | `true` (or `{ capture: true }`) | `false` (the default) |
+| Default behavior | Off; must opt in | On; every listener bubbles by default |
+| Effect of `event.stopPropagation()` | Stops the event before it reaches the target | Stops the event before higher ancestors see it |
+| Common use cases | Intercepting non-bubbling events; pre-empting child handlers; analytics | Most click, input, and change handlers; event delegation |
+
+## When to use the capture phase in real apps
+
+In practice, the capture phase is the right tool for three specific situations:
+
+1. **Delegating non-bubbling events.** `focus`, `blur`, `scroll`, and `mouseenter`/`mouseleave` do not bubble, but they are visible to ancestors during the capture phase. Adding `addEventListener('focus', handler, true)` to a form gives you a delegated focus listener for every input inside it.
+
+   ```js
+   form.addEventListener(
+     'focus',
+     (event) => {
+       highlightField(event.target);
+     },
+     true, // capture: catches focus events before they stop at the input
+   );
+   ```
+
+2. **Pre-empting child handlers** for analytics or feature gates. The capture phase runs before any child's bubble handler, so a region-wide "intercept clicks" listener can record the click (or block the action with `stopPropagation()`) before component code sees it.
+
+3. **Modal libraries that need first-look at clicks.** A modal dialog often listens at the document level with `capture: true` for outside-click dismissal. Using the bubble phase would let inner handlers call `stopPropagation()` and accidentally prevent the modal from closing.
+
+## `stopPropagation()` in capture vs bubble
+
+`stopPropagation()` blocks all subsequent phases, not just the next ancestor.
+
+```js live
+const outer = document.createElement('div');
+const inner = document.createElement('button');
+outer.appendChild(inner);
+document.body.appendChild(outer);
+
+outer.addEventListener(
+  'click',
+  (event) => {
+    console.log('outer capture: stopping here');
+    event.stopPropagation();
+  },
+  true,
+);
+inner.addEventListener('click', () => console.log('inner target'));
+outer.addEventListener('click', () => console.log('outer bubble'));
+
+inner.click();
+// Output: 'outer capture: stopping here'
+// The target handler and bubble handler are both skipped.
+```
+
+Calling `stopPropagation()` during the capture phase prevents the target's own handlers and every bubble-phase ancestor from running. This is useful for an "intercept and replace" pattern, but if the target needs to keep working, listen during the bubble phase instead.
+
+There is also `event.stopImmediatePropagation()`, which additionally prevents other listeners on the same element (registered in the same phase) from firing. Use it when multiple scripts add listeners to the same element and only one of them should run.
 
 ## Further reading
 
diff --git a/questions/describe-the-difference-between-a-cookie-sessionstorage-and-localstorage/en-US.mdx b/questions/describe-the-difference-between-a-cookie-sessionstorage-and-localstorage/en-US.mdx
index 59bc415..ea23592 100644
--- a/questions/describe-the-difference-between-a-cookie-sessionstorage-and-localstorage/en-US.mdx
+++ b/questions/describe-the-difference-between-a-cookie-sessionstorage-and-localstorage/en-US.mdx
@@ -137,6 +137,75 @@ sessionStorage.removeItem('key');
 sessionStorage.clear();
 ```
 
+## Security
+
+A side-by-side feature comparison hides the most important practical difference between these three: how each one behaves under XSS.
+
+|  | Cookie | `localStorage` / `sessionStorage` |
+| --- | --- | --- |
+| Reachable from arbitrary JS on the origin | Only if not `HttpOnly` | Always |
+| `HttpOnly` flag (cannot be read from JS) | Yes | No equivalent |
+| `Secure` flag (HTTPS-only transport) | Yes | N/A (values never leave the client unless your code sends them) |
+| `SameSite` flag (CSRF defense: `Strict`, `Lax`, `None`) | Yes | N/A |
+| Partitioned cookies (CHIPS, isolated per top-level site) | Yes (modern browsers) | N/A |
+| Survives an XSS exploit | An `HttpOnly` cookie does | All values are exfiltrable |
+
+The practical takeaways:
+
+- **Auth and session tokens belong in `HttpOnly; Secure; SameSite=Lax` cookies, not in `localStorage`.** Any XSS bug in any script on the origin can read everything in `localStorage`. An `HttpOnly` cookie cannot be read by JavaScript at all, so the attacker would have to make requests through the user's browser, which CSRF defenses (`SameSite`, double-submit tokens) are designed to block.
+- **CSRF vs XSS is the trade-off.** Cookies need CSRF protection; `localStorage` tokens (with the Authorization-header pattern) do not. The cookie plus `SameSite=Lax` combination is generally considered safer because it survives XSS, and `SameSite=Lax` blocks the most common CSRF cases by default.
+- **`localStorage` is fine for non-sensitive client state**: theme preferences, layout settings, draft text, recently viewed items.
+
+## Real-world set, get, and remove
+
+The three APIs look superficially similar but have meaningfully different ergonomics. Here is the same operation in each:
+
+```js
+// localStorage: synchronous, string-only
+localStorage.setItem('user', JSON.stringify({ id: 1, name: 'Ada' }));
+const user = JSON.parse(localStorage.getItem('user') ?? 'null');
+localStorage.removeItem('user');
+
+// sessionStorage: same shape, scoped to the tab
+sessionStorage.setItem('draft', 'hello');
+const draft = sessionStorage.getItem('draft');
+sessionStorage.removeItem('draft');
+
+// Cookie: modern async API (where supported)
+await cookieStore.set({
+  name: 'session',
+  value: 'abc123',
+  sameSite: 'Lax',
+  secure: true,
+  expires: Date.now() + 7 * 24 * 60 * 60 * 1000,
+});
+const session = await cookieStore.get('session');
+await cookieStore.delete('session');
+
+// Cookie: legacy `document.cookie` API (universally supported)
+document.cookie =
+  'session=abc123; Path=/; Max-Age=604800; SameSite=Lax; Secure';
+// Reading a specific cookie still requires parsing the string yourself:
+const value = document.cookie
+  .split('; ')
+  .find((row) => row.startsWith('session='))
+  ?.split('=')[1];
+```
+
+A few common mistakes:
+
+- `localStorage` and `sessionStorage` only store strings. `localStorage.setItem('count', 0)` stores `"0"` and `localStorage.getItem('count')` returns `"0"` (a string). Always serialize and deserialize explicitly.
+- Assigning `document.cookie = '...'` does not clear other cookies. Each assignment sets or updates a single cookie. To delete one, set it again with `Max-Age=0` or an `expires` date in the past.
+- `cookieStore.set` is async; `localStorage.setItem` is synchronous. Mixing them in the same logic without awaiting the cookie call leads to ordering bugs.
+
+## Beyond these three: IndexedDB and Cache Storage
+
+Modern apps frequently need more than what these three APIs offer. Two more are worth knowing:
+
+- **IndexedDB**: an in-browser, asynchronous, transactional database. Use it for large structured data (offline app state, large user-generated content, search indexes), MBs to GBs of storage, and queryable data. Wrappers like [Dexie.js](https://dexie.org/) and [idb](https://github.com/jakearchibald/idb) make the API more pleasant.
+- **Cache Storage** (`caches`): paired with [Service Workers](https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API), this stores HTTP request/response pairs for offline-capable apps and PWAs. It is not a general-purpose key-value store; it is specifically for caching network responses.
+- **`localStorage` is for simple key-value config only.** If you find yourself JSON-stringifying complex nested data into `localStorage`, IndexedDB is usually a better fit.
+
 ## Notes
 
 There are also other client-side storage mechanisms like [IndexedDB](https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API) which is more powerful than the above-mentioned technologies but more complicated to use.
diff --git a/questions/describe-the-difference-between-script-async-and-script-defer/en-US.mdx b/questions/describe-the-difference-between-script-async-and-script-defer/en-US.mdx
index 114df87..5227edc 100644
--- a/questions/describe-the-difference-between-script-async-and-script-defer/en-US.mdx
+++ b/questions/describe-the-difference-between-script-async-and-script-defer/en-US.mdx
@@ -10,13 +10,13 @@ All of these ways (`<script>`, `<script async>`, and `<script defer>`) are used
 - `<script async>` downloads the script asynchronously, in parallel with parsing the HTML. Executes the script as soon as it is available, potentially interrupting the HTML parsing. Multiple `<script async>` tags do not wait for each other and execute in no particular order.
 - `<script defer>` downloads the script asynchronously, in parallel with parsing the HTML. However, the execution of the script is deferred until HTML parsing is complete, in the order they appear in the HTML.
 
-Here's a table summarizing the 3 ways of loading `<script>`s in an HTML document.
+Here's a table summarizing the 4 ways of loading `<script>`s in an HTML document. Modern apps almost always use modules, which deserve their own row.
 
-| Feature | `<script>` | `<script async>` | `<script defer>` |
-| --- | --- | --- | --- |
-| Parsing behavior | Blocks HTML parsing | Runs parallel to parsing | Runs parallel to parsing |
-| Execution order | In order of appearance | Not guaranteed | In order of appearance |
-| DOM dependency | No | No | Yes (waits for DOM) |
+| Feature | `<script>` | `<script async>` | `<script defer>` | `<script type="module">` |
+| --- | --- | --- | --- | --- |
+| Parsing behavior | Blocks HTML parsing | Downloads in parallel; execution still blocks parsing | Downloads in parallel; execution deferred until after parsing | Downloads in parallel; execution deferred until after parsing |
+| Execution order | In order of appearance | Not guaranteed | In order of appearance | In order of appearance, with each script's `import` dependencies resolved first |
+| DOM dependency | No | No | Yes (waits for DOM) | Yes (waits for DOM) |
 
 ---
 
@@ -106,10 +106,59 @@ If a script relies on a fully-parsed DOM, the `defer` attribute will be useful i
 </html>
 ```
 
+## `<script type="module">`
+
+Module scripts are the standard entry point for projects built with Vite (and many other modern bundlers). Next.js doesn't always emit `type="module"` for its own runtime, but most application code authored as ES modules ends up running through one of these tags. They behave like `defer` scripts with two important additions: dependencies declared with `import` are loaded and executed in the right order, and module code is strict by default.
+
+```html
+<script type="module" src="/src/main.js"></script>
+```
+
+Behavior:
+
+- **Parsing**: deferred. HTML parsing continues; the script does not block.
+- **Execution**: runs after the document has finished parsing. Across multiple `<script type="module">` tags in the same document, execution follows document order, but each script's `import` dependencies are resolved and executed first.
+- **DOM ready**: the DOM is parsed before the module runs.
+- **Strict mode**: enforced automatically; no `'use strict'` directive needed.
+- **CORS**: module scripts are always fetched with CORS, so the server must send `Access-Control-Allow-Origin` for cross-origin loads. The `crossorigin` attribute itself is not required for the module to load — it only controls whether credentials (cookies, HTTP auth) are sent on cross-origin requests (`crossorigin` or `crossorigin="anonymous"` omits them; `crossorigin="use-credentials"` sends them). Adding it is still recommended for explicit credentials handling and for full error details in `error` event handlers.
+
+Use `<script type="module">` for new front-end code. If you have an independent module-script entry point and document order does not matter, combine with `async`:
+
+```html
+<script async type="module" src="/analytics-module.js"></script>
+```
+
+## Which to use: a decision matrix
+
+| Script type | Use for |
+| --- | --- |
+| `<script>` (no attrs) | Critical inline scripts that must run synchronously before the next HTML element parses. |
+| `<script async>` | Independent third-party scripts where order does not matter (analytics, ads, monitoring beacons). |
+| `<script defer>` | Classic (non-module) app scripts where order matters and the DOM should be ready. |
+| `<script type="module">` | ES module entry points. The default for Vite, Next.js client code, and any new project. |
+| `<script async type="module">` | Module scripts where order does not matter. Most apps want default module behavior instead. |
+
+## How modern frameworks load scripts
+
+It also helps to know what the tools you use actually generate.
+
+- **Vite**: emits `<script type="module" crossorigin src="...">` for the entry chunk in production. Dynamic `import()` calls become `<link rel="modulepreload">` hints plus lazy module fetches.
+- **Next.js**: provides a built-in `<Script>` component with `strategy` props such as `beforeInteractive` (loaded and executed before page hydration), `afterInteractive` (default, like `defer`), `lazyOnload` (after the page is idle), and `worker` (offloaded to Partytown).
+- **CDN-injected scripts** (Google Analytics, Plausible, Sentry, etc.) are almost always recommended as `async`, because they are independent. Loading them with `defer` or no attribute slows down the page for no reason.
+- **CRA and older webpack apps** typically emit `<script defer src="..."></script>` for the runtime and chunk entries. CRA itself is deprecated, and new projects should use Vite or Next.js.
+
+## Common bugs from the wrong attribute choice
+
+- **Analytics with `defer` instead of `async`.** `defer` waits for HTML parsing, so a third-party tag at the top of the page artificially extends `DOMContentLoaded`. Use `async` for any independent third-party tag.
+- **App entry as `async` script.** If `app.js` and `vendor.js` are loaded with `async`, they can execute in any order. `app.js` may run before `vendor.js` finishes, which throws `ReferenceError` for the missing globals. Use `defer` (or modules) for app scripts.
+- **`document.write` inside a `defer` or `async` script.** Browsers ignore `document.write()` calls from async or deferred scripts with a console warning: "A call to document.write() from an asynchronously-loaded external script was ignored." The script would need to be a regular blocking `<script>` for the call to take effect, though `document.write` should be avoided in any new code.
+- **Module script in a `<script>` tag without `type="module"`.** Top-level `import` statements throw `SyntaxError`. Either set `type="module"` or use a bundler.
+- **Cross-origin module served without CORS headers.** Module scripts are always fetched with CORS, so a cross-origin URL like `<script type="module" src="https://cdn.example.com/lib.js">` will fail to load if the server doesn't send `Access-Control-Allow-Origin`. The fix is on the server side — adding `crossorigin` to the tag does not bypass this requirement (though it is still recommended for better error reporting and explicit credentials handling).
+
 ## Notes
 
 - The `async` attribute should be used for scripts that are not critical to the initial rendering of the page and do not depend on each other, while the `defer` attribute should be used for scripts that depend on or are depended on by another script.
-- The `async` and `defer` attributes are ignored for scripts that have no `src` attribute.
+- The `async` and `defer` attributes are ignored for inline scripts (scripts with no `src` attribute).
 - `<script>`s with `defer` or `async` that contain `document.write()` will be ignored with a message like "A call to `document.write()` from an asynchronously-loaded external script was ignored".
 - Even though `async` and `defer` help to make script downloading asynchronous, the scripts are still eventually executed on the main thread. If these scripts are computationally intensive, it can result in laggy/frozen UI. [Partytown](https://partytown.qwik.dev/) is a library that helps relocate script executions into a [web worker](https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API) and off the [main thread](https://developer.mozilla.org/en-US/docs/Glossary/Main_thread), which is great for third-party scripts where you do not have control over the code.
 
diff --git a/questions/explain-event-delegation/en-US.mdx b/questions/explain-event-delegation/en-US.mdx
index 54b2115..ed5a1d1 100644
--- a/questions/explain-event-delegation/en-US.mdx
+++ b/questions/explain-event-delegation/en-US.mdx
@@ -110,13 +110,175 @@ userForm.addEventListener('input', (event) => {
 
 In this example, a single input event listener is attached to the form element. It can respond to input changes for all child input elements, simplifying the code by eliminating the need for individual listeners on each `<input>` element.
 
+## More real-world delegation patterns
+
+Beyond the simple list-item example, three patterns show up constantly in production code.
+
+### Form-wide delegated change handler
+
+A single `change` or `input` listener on the form catches every input update, which is useful for autosave, dirty-tracking, and validation:
+
+```js
+// HTML: <form id="profile-form"> with many inputs/selects/textareas inside
+
+const form = document.getElementById('profile-form');
+
+form.addEventListener('input', (event) => {
+  // Works for any <input>, <select>, or <textarea> the form contains,
+  // even ones added later by the user.
+  const field = event.target;
+  console.log(`${field.name} changed to ${field.value}`);
+  scheduleAutosave(field.name, field.value);
+});
+```
+
+No matter how many fields the form has, or whether new fields are appended dynamically, only one listener is needed.
+
+### Data-table row actions
+
+Modern data-table UIs commonly use a single click handler on the table that reads `data-action` from the clicked element to know what to do. This is delegation plus the **data-attribute pattern**:
+
+```js
+// HTML rows look like:
+// <tr>
+//   <td>...</td>
+//   <td>
+//     <button data-action="edit" data-id="42">Edit</button>
+//     <button data-action="delete" data-id="42">Delete</button>
+//   </td>
+// </tr>
+
+document.querySelector('table').addEventListener('click', (event) => {
+  const button = event.target.closest('[data-action]');
+  if (!button) {
+    return;
+  }
+  const { action, id } = button.dataset;
+  if (action === 'edit') {
+    openEditor(id);
+  }
+  if (action === 'delete') {
+    confirmDelete(id);
+  }
+});
+```
+
+`event.target.closest()` is the workhorse here. It walks up from the click target to the nearest matching ancestor, which makes the handler robust against inner spans, icons, and styling wrappers.
+
+### Click-to-edit cells
+
+A spreadsheet-style cell editor uses delegation to promote whichever cell was clicked into an editable input, without attaching one listener per cell:
+
+```js
+document.querySelector('table').addEventListener('click', (event) => {
+  const cell = event.target.closest('td.editable');
+  if (!cell || cell.querySelector('input')) {
+    return; // already editing
+  }
+
+  const original = cell.textContent;
+  const input = document.createElement('input');
+  input.value = original;
+  cell.textContent = '';
+  cell.appendChild(input);
+  input.focus();
+
+  input.addEventListener('blur', () => {
+    cell.textContent = input.value;
+    if (input.value !== original) saveCell(cell.dataset.id, input.value);
+  });
+});
+```
+
+## Delegating non-bubbling events
+
+The TL;DR notes that `focus`, `blur`, `scroll`, `mouseenter`, `mouseleave`, and `resize` do not bubble, so the obvious delegation pattern (one listener on the parent) does not work for them. Two solid workarounds:
+
+### Use the capture phase
+
+Pass a third argument of `true` (or `{ capture: true }`) to listen during the capture phase. The event is visible to ancestors on the way down to the target, even if it does not bubble back up:
+
+```js live
+document.body.innerHTML = `
+  <div id="form">
+    <input id="a" placeholder="A">
+    <input id="b" placeholder="B">
+  </div>
+`;
+
+document.getElementById('form').addEventListener(
+  'focus',
+  (event) => {
+    console.log('focused:', event.target.id);
+  },
+  true, // capture: catch focus before it stops at the input
+);
+
+// In a real page, focus events fire automatically when the user clicks or
+// tabs into an input. Here we dispatch them by hand so the demo prints the
+// same sequence in this playground.
+['a', 'b'].forEach((id) => {
+  document.getElementById(id).dispatchEvent(new FocusEvent('focus'));
+});
+// Logs: focused: a, then focused: b
+```
+
+### Use the bubbling siblings: `focusin` and `focusout`
+
+`focus` does not bubble, but `focusin` does. The same is true for `blur` and `focusout`. The pointer events have similar pairs: `mouseover` and `mouseout` bubble, while `mouseenter` and `mouseleave` do not (note that `mouseover` and `mouseout` also fire when the pointer crosses descendant boundaries, so the semantics are slightly different). The bubbling variants exist specifically to support delegation:
+
+```js live
+document.body.innerHTML = `
+  <form id="form">
+    <input id="a" placeholder="A">
+    <input id="b" placeholder="B">
+  </form>
+`;
+
+const form = document.getElementById('form');
+form.addEventListener('focusin', (event) =>
+  console.log('focusin:', event.target.id),
+);
+form.addEventListener('focusout', (event) =>
+  console.log('focusout:', event.target.id),
+);
+
+// In a real page, focusin and focusout fire automatically when the user
+// moves between inputs. Here we dispatch them by hand to simulate the user
+// moving focus from input A to input B inside this playground.
+const a = document.getElementById('a');
+const b = document.getElementById('b');
+
+[
+  [a, 'focusin'], // focusin: a
+  [a, 'focusout'], // focusout: a
+  [b, 'focusin'], // focusin: b
+].forEach(([el, type]) => {
+  el.dispatchEvent(new FocusEvent(type, { bubbles: true }));
+});
+```
+
+For `scroll`, the bubbling-sibling approach does not exist. Capture-phase delegation technically works (capture-phase listeners on ancestors do receive scroll events from descendants), but it is rarely a good idea: scroll events fire many times per second, you would receive them for every nested scroller in the subtree, and there is no `event.target` filtering that beats just attaching a listener directly to the scrollable element. Use one direct listener instead. (`window` scroll has nothing higher to delegate to anyway.)
+
+## Performance: when delegation actually helps
+
+The common claim is "delegation is faster because there are fewer listeners." That is partly true but often overstated.
+
+- **Listener count is rarely the bottleneck.** On modern browsers, attaching 100 vs 10,000 click listeners is still sub-millisecond. Adding listeners is almost free, and dispatching a click is fast either way.
+- **Memory is the meaningful win.** Each direct listener creates a closure that holds references to its enclosing scope. With 10,000 rows, that is 10,000 closures kept alive, which can become noticeable. One delegated listener is one closure.
+- **Dynamic content is the structural win.** With direct listeners, you have to attach (and detach) listeners on every DOM mutation, which is easy to leak. Delegation just works for elements added later, and that is the main reason most code uses it.
+- **Delegation is not always faster at runtime.** A delegated handler runs `event.target.closest(...)` on every event, which is cheap but not free. For a small fixed number of elements with stable handlers, attaching directly is fine and arguably cleaner.
+
+Use delegation for memory, dynamic content, and code simplicity, not because direct listeners are inherently slow.
+
 ## Pitfalls
 
-Do note that event delegation comes with certain pitfalls:
+Event delegation comes with several pitfalls:
 
-- **Incorrect target handling:** Ensure correct identification of the event target to avoid unintended actions.
-- **Not all events can be delegated/bubbled**: Not all events can be delegated because they are not bubbled. Non-bubbling events include: `focus`, `blur`, `scroll`, `mouseenter`, `mouseleave`, `resize`, etc.
-- **Event overhead:** While event delegation is generally more efficient, complex logic may need to be written within the root event listener to identify the triggering element and respond appropriately. This can introduce overhead and can be potentially more complex if not managed properly.
+- **Incorrect target handling.** Use `event.target.closest(selector)` rather than checking `event.target.tagName` directly. Clicks on inner elements (icons, spans) will otherwise miss the match.
+- **Not all events bubble.** `focus`, `blur`, `scroll`, `mouseenter`, `mouseleave`, and `resize` do not bubble. Use the capture phase or the bubbling alternatives (`focusin`, `focusout`, `mouseover`, `mouseout`) shown above.
+- **`stopPropagation()` inside the tree breaks delegation.** If a child handler calls `event.stopPropagation()`, the delegated handler at the ancestor never fires. This is a common source of "my handler doesn't run" bugs.
+- **Event overhead.** Complex routing logic inside the root listener can become hard to maintain. Use small dispatch tables (`{ edit: ..., delete: ... }`) rather than long `if/else` chains.
 
 ## Event delegation in JavaScript frameworks
 
diff --git a/questions/explain-the-concept-of-debouncing-and-throttling/en-US.mdx b/questions/explain-the-concept-of-debouncing-and-throttling/en-US.mdx
index c1cbbe4..3570cf5 100644
--- a/questions/explain-the-concept-of-debouncing-and-throttling/en-US.mdx
+++ b/questions/explain-the-concept-of-debouncing-and-throttling/en-US.mdx
@@ -49,17 +49,15 @@ let intervalId = setInterval(() => {
 
 ---
 
-## Debouncing and throttling
+## What is debouncing in JavaScript?
 
-### Debouncing
+Debouncing is a technique that ensures a function only executes after a specified period of inactivity. Every time the function is called, the timer resets. Only when the calls stop for the specified delay does the function actually run.
 
-Debouncing is a technique used to ensure that a function is only executed after a certain amount of time has passed since it was last invoked. This is particularly useful in scenarios where you want to limit the number of times a function is called, such as when handling user input events like keypresses or mouse movements.
-
-#### Example use case
+### Example use case
 
 Imagine you have a search input field and you want to make an API call to fetch search results. Without debouncing, an API call would be made every time the user types a character, which could lead to a large number of unnecessary calls. Debouncing ensures that the API call is only made after the user has stopped typing for a specified amount of time.
 
-#### Code example
+### Code example
 
 ```js
 function debounce(func, delay) {
@@ -81,15 +79,15 @@ document.getElementById('searchInput').addEventListener('input', (event) => {
 });
 ```
 
-### Throttling
+## What is throttling in JavaScript?
 
-Throttling is a technique used to ensure that a function is called at most once in a specified time interval. This is useful in scenarios where you want to limit the number of times a function is called, such as when handling events like window resizing or scrolling.
+Throttling is a technique that ensures a function runs at most once per specified time interval, no matter how often it is invoked. Calls in between are dropped (or coalesced into the next interval).
 
-#### Example use case
+### Example use case
 
 Imagine you have a function that updates the position of elements on the screen based on the window size. Without throttling, this function could be called many times per second as the user resizes the window, leading to performance issues. Throttling ensures that the function is only called at most once in a specified time interval.
 
-#### Code example
+### Code example
 
 ```js live
 function throttle(func, limit) {
@@ -106,12 +104,168 @@ function throttle(func, limit) {
 // Usage
 const handleResize = throttle(() => {
   // Update element positions
-  console.log('Window resized');
+  console.log('Window resized at', new Date().toLocaleTimeString());
+}, 1000);
+
+// In a real app you'd just do: window.addEventListener('resize', handleResize)
+// The setInterval below only exists to drive the demo in the playground.
+let count = 0;
+const intervalId = setInterval(() => {
+  handleResize();
+  if (++count >= 30) clearInterval(intervalId);
 }, 100);
+// 'Window resized' is logged at most once per second despite 10 calls/second
+```
+
+## Debounce vs throttle: what's the difference?
+
+|  | Debounce | Throttle |
+| --- | --- | --- |
+| When does the function fire? | After a quiet period (no calls for `delay` ms) | At most once per `interval` ms while calls keep coming |
+| What happens to intermediate calls? | All but the most recent are dropped | All but the first per interval are dropped (or coalesced if trailing edge is enabled) |
+| Worst-case latency | Unbounded: if calls never stop, the function never fires | Bounded: fires at least once per `interval` |
+| Output cadence with rapid-fire input | One call after silence | Steady stream, one per `interval` |
+| Best for | "Wait until the user is done": search-as-you-type, autosave-after-edits, validation-after-input | "Sample at a rate I control": scroll, mousemove, resize, drag |
+
+In one line: debounce coalesces a burst of calls into one call at the end; throttle limits the burst to a steady cadence.
+
+## Leading and trailing edges
+
+Production implementations of debounce and throttle (such as Lodash's) accept `leading` and `trailing` flags. The basic implementations above are trailing-only debounce and leading-only throttle, which is why they often surprise candidates in interviews.
+
+| Function | `leading` default | `trailing` default | Behavior |
+| --- | --- | --- | --- |
+| `_.debounce(fn, wait)` | `false` | `true` | Fires only at the end of the quiet period |
+| `_.throttle(fn, wait)` | `true` | `true` | Fires at the start AND at the end of each interval |
+
+Here is a debounce that supports both edges plus a `maxWait` cap (so it cannot defer forever):
+
+```js
+function debounce(
+  fn,
+  wait,
+  { leading = false, trailing = true, maxWait } = {},
+) {
+  let timer = null;
+  let lastCall = 0;
+  let lastInvoke = 0;
+  let lastArgs;
+  let lastThis;
+
+  function invoke(time) {
+    lastInvoke = time;
+    const args = lastArgs;
+    const ctx = lastThis;
+    lastArgs = lastThis = null;
+    fn.apply(ctx, args);
+  }
 
-window.addEventListener('resize', handleResize);
+  return function debounced(...args) {
+    const now = Date.now();
+    const isFirstCall = lastCall === 0;
+    lastCall = now;
+    lastArgs = args;
+    lastThis = this;
+
+    if (timer) clearTimeout(timer);
+
+    if (leading && isFirstCall) invoke(now);
+
+    const remainingWait = maxWait
+      ? Math.min(wait, maxWait - (now - lastInvoke))
+      : wait;
+
+    timer = setTimeout(() => {
+      timer = null;
+      if (trailing && lastArgs) invoke(Date.now());
+      lastCall = 0;
+    }, remainingWait);
+  };
+}
 ```
 
+## Predict the output
+
+### Debounce closure: which call wins?
+
+What does this print?
+
+```js live
+function debounce(fn, delay) {
+  let t;
+  return (...args) => {
+    clearTimeout(t);
+    t = setTimeout(() => fn(...args), delay);
+  };
+}
+
+const log = debounce((x) => console.log(x), 100);
+for (var i = 0; i < 3; i++) log(i);
+// What gets logged?
+```
+
+Only `2` is logged, once. The first two calls are cancelled by `clearTimeout`, and only the last `args` (when `i === 2`) survives. This is the defining behavior of trailing-edge debounce: the call fires with the most recent arguments after the quiet period. The `var` is incidental; the debounce is what drops the earlier calls.
+
+### Throttle drops the trailing call
+
+This is one of the most common debounce/throttle interview bugs. The basic throttle from earlier looks correct, but has a subtle problem:
+
+```js live
+function throttle(fn, limit) {
+  let inThrottle = false;
+  return function (...args) {
+    if (!inThrottle) {
+      fn.apply(this, args);
+      inThrottle = true;
+      setTimeout(() => (inThrottle = false), limit);
+    }
+  };
+}
+
+const log = throttle((x) => console.log('fired:', x), 100);
+log(1); // fires: 1
+log(2); // dropped (inside cooldown)
+log(3); // dropped (inside cooldown)
+// 100ms later: nothing fires, even though log(3) was the latest
+```
+
+The fix is to queue the latest arguments and invoke them when the cooldown ends, so the user does not lose the final state of a drag, scroll, or resize. Lodash does this by default via its `trailing: true` option.
+
+### `requestAnimationFrame` throttle
+
+For scroll and pointer handlers, time-based throttle is the wrong tool. The browser paints at the display refresh rate (typically 60Hz, or 16.7ms per frame), and `setTimeout` does not align with that. The handler can fire mid-paint and cause jank. Use `requestAnimationFrame` instead:
+
+```js live
+function rafThrottle(fn) {
+  let queued = false;
+  let lastArgs;
+  return function (...args) {
+    lastArgs = args;
+    if (queued) return;
+    queued = true;
+    requestAnimationFrame(() => {
+      fn.apply(this, lastArgs);
+      queued = false;
+    });
+  };
+}
+
+const onScroll = rafThrottle((y) => console.log('scrollY:', y));
+onScroll(10);
+onScroll(20);
+onScroll(30); // only the latest fires once per frame
+```
+
+`rafThrottle` automatically scales with the user's monitor (smooth on 120Hz, fewer paints on 30Hz) and never causes wasted work between paints.
+
+## Common mistakes
+
+- **Treating debounce and throttle as interchangeable.** Saying "I'd use debounce for scroll" is wrong: scroll wants throttle (or `requestAnimationFrame`). Debounce on scroll only fires when the user stops scrolling.
+- **Forgetting `this` and `args` in the inner function.** `setTimeout(fn, delay)` loses both, so the wrapper must call `fn.apply(this, args)` to preserve them.
+- **No cleanup in React.** Returning a debounced function from a render without `useMemo` or `useCallback` creates a new debouncer on every render, which means the timer is never actually cleared. On unmount, the trailing call also still fires on a dead component (use `cancel()` or `useEffect` cleanup).
+- **Picking throttle when the requirement is "wait until they stop."** Autosave-on-edit is a debounce problem; throttling it means saving mid-typing.
+- **Picking debounce when latency matters.** A debounced save with no `maxWait` can defer indefinitely if the user keeps typing. The user navigates away, and the save never fires.
+
 ## Further reading
 
 - [Debouncing and Throttling Explained Through Examples](https://css-tricks.com/debouncing-throttling-explained-examples/)
diff --git a/questions/explain-the-difference-between-documentqueryselector-and-documentgetelementbyid/en-US.mdx b/questions/explain-the-difference-between-documentqueryselector-and-documentgetelementbyid/en-US.mdx
index 8eb0831..ef903e8 100644
--- a/questions/explain-the-difference-between-documentqueryselector-and-documentgetelementbyid/en-US.mdx
+++ b/questions/explain-the-difference-between-documentqueryselector-and-documentgetelementbyid/en-US.mdx
@@ -52,6 +52,82 @@ const elementById = document.getElementById('my-id');
 - **Return value**: `document.querySelector()` returns the first matching element, whereas `document.getElementById()` returns the element with the specified ID.
 - **Performance**: `document.getElementById()` is generally faster because it directly accesses the element by ID, while `document.querySelector()` has to parse the CSS selector.
 
+## The full DOM-query method comparison
+
+`querySelector` and `getElementById` are two of the seven main DOM-query methods. The most important practical distinction across all of them is whether the result is a live or a static collection.
+
+| Method | Selector input | Returns | Live? | When to use |
+| --- | --- | --- | --- | --- |
+| `getElementById(id)` | id string | `Element` or `null` | No (single element) | Single element by id; hot-path code |
+| `querySelector(sel)` | Any CSS selector | First match or `null` | No (snapshot) | First element matching any selector |
+| `querySelectorAll(sel)` | Any CSS selector | Static `NodeList` | No (snapshot) | All matches as a frozen list |
+| `getElementsByClassName(name)` | Class name | `HTMLCollection` | Yes (auto-updates) | When you need a live collection |
+| `getElementsByTagName(tag)` | Tag name | `HTMLCollection` | Yes | Same |
+| `getElementsByName(name)` | `name` attribute | `NodeList` | Yes | Form elements by `name` |
+| `closest(sel)` | Any CSS selector | Nearest matching ancestor (or self) or `null` | N/A | Walking up from a target inside event handlers |
+
+The live vs snapshot distinction is a common source of subtle bugs.
+
+## Live vs static collections (predict the output)
+
+```js live
+document.body.innerHTML = '<div class="x"></div><div class="x"></div>';
+
+const live = document.getElementsByClassName('x'); // HTMLCollection (live)
+const snapshot = document.querySelectorAll('.x'); // NodeList (static)
+
+console.log('before:', live.length, snapshot.length); // 2, 2
+
+document.body.insertAdjacentHTML('beforeend', '<div class="x"></div>');
+
+console.log('after: ', live.length, snapshot.length); // 3, 2
+```
+
+The live `HTMLCollection` updates automatically when DOM nodes are added or removed. The static `NodeList` from `querySelectorAll` does not.
+
+This matters in practice in two specific ways:
+
+- **Iterating a live collection while mutating it** is a classic infinite-loop bug. Reading `live[i]` after appending more matching nodes hits the new ones too, and the `for` loop never finishes.
+- **Caching a `querySelectorAll` result** is safe; caching `getElementsByClassName` is not. The cached reference silently changes as the DOM changes.
+
+Prefer `querySelectorAll` for most modern use cases (it has `forEach`, and array spread `[...]` works on it). Reach for the live collections only when you specifically want auto-updating behavior.
+
+## Performance: how much does it actually matter?
+
+The "`getElementById` is faster" claim is technically true but practically irrelevant in nearly all code:
+
+- A single call to any of these methods on a typical page takes well under a microsecond on modern browsers. Engines maintain an internal id-to-element map for `getElementById`, and they typically optimize `querySelector('#myId')` to use the same fast path for the simple `#id` selector form.
+- The performance gap only matters inside hot loops doing tens of thousands of calls per frame, such as interactive canvases, grid renderers, and animation systems. In ordinary application code (event handlers, init code, framework hooks), choose by clarity, not micro-benchmarks.
+- For complex selectors (such as `'div.menu > a:nth-child(odd)'`), `querySelector` parses the selector on every call (engines may cache internally, but it is not guaranteed by the spec). The cost is small per call and well under the 16ms budget for a 60Hz frame, but it does add up in tight loops — cache the result if you query the same selector repeatedly.
+
+If you genuinely need maximum speed for repeated lookups, cache the reference:
+
+```js
+const button = document.getElementById('action'); // cache once
+button.addEventListener('click', handle); // reuse forever
+```
+
+The common waste is re-querying inside event handlers, not the choice between methods.
+
+## What about `closest()`, `matches()`, and `contains()`?
+
+Three more methods round out the modern DOM-query toolkit:
+
+- `element.closest(selector)` walks up from the element (including the element itself) and returns the nearest ancestor matching the selector, or `null`. It is constantly useful in event-delegation handlers:
+
+  ```js
+  table.addEventListener('click', (event) => {
+    const row = event.target.closest('tr[data-id]');
+    if (row) editRow(row.dataset.id);
+  });
+  ```
+
+- `element.matches(selector)` returns `true` or `false` for whether the element matches the CSS selector. Useful inside delegated handlers when you want to confirm the target type without a `tagName` check.
+
+- `parent.contains(child)` returns `true` if `child` is `parent` or anywhere inside it. Useful for outside-click detection: `if (!modal.contains(event.target)) close()`.
+
+These three plus `querySelector` and `querySelectorAll` form the modern toolkit. The older `getElementsBy*` methods are legacy and rarely the right default in new code.
+
 ## Further reading
 
 - [MDN Web Docs: document.querySelector()](https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector)
diff --git a/questions/how-is-promiseall-different-from-promiseallsettled/en-US.mdx b/questions/how-is-promiseall-different-from-promiseallsettled/en-US.mdx
index 910496d..114e7c3 100644
--- a/questions/how-is-promiseall-different-from-promiseallsettled/en-US.mdx
+++ b/questions/how-is-promiseall-different-from-promiseallsettled/en-US.mdx
@@ -96,6 +96,80 @@ Promise.allSettled([promise1, promise2, promise3]).then((results) => {
 
 In this example, `Promise.allSettled()` resolves with an array of result objects, including the rejected promise with its reason.
 
+## When to use `Promise.all()` vs `Promise.allSettled()`
+
+The choice comes down to a single question: if one of these operations fails, is the rest of the work still useful?
+
+### Use `Promise.all()` when partial success is invalid
+
+- **Prefetching everything a page needs before render**: if any required call fails (auth, feature flags, current user), you want to render an error state, not a half-broken UI.
+- **Transactional sequences**: booking a flight, hotel, and rental car in parallel. If the flight fails, the other reservations should not silently succeed.
+- **Gating UI on multiple checks**: show the dashboard only if `getUser()` AND `getPermissions()` both succeed. Fail-fast is the desired behavior.
+
+### Use `Promise.allSettled()` when partial success is acceptable
+
+- **Dashboard with multiple independent widgets**: six analytics endpoints fan out in parallel. One slow or failing endpoint should not blank the rest of the dashboard.
+- **Bulk operations with per-item feedback**: deleting 50 selected rows; the UI needs to show which succeeded and which failed, not abort on the first failure.
+- **Analytics or telemetry batches**: sending several events where partial loss is acceptable; you want to know which fired even if one rejected.
+
+If you would `try/catch` each call individually anyway, `Promise.allSettled()` is what you actually want.
+
+## Failure-mode reference
+
+| Input scenario | `Promise.all()` | `Promise.allSettled()` |
+| --- | --- | --- |
+| Empty iterable `[]` | Resolves with `[]` synchronously | Resolves with `[]` synchronously |
+| Mix of promises and non-promise values | Wraps non-promises with `Promise.resolve` | Wraps non-promises with `Promise.resolve` |
+| One rejection, others pending | Rejects immediately with first reason; others keep running but their results are ignored | Waits for all; returns one `{status:'rejected'}` entry |
+| Synchronous `throw` inside the iterable iterator | Returned promise rejects | Returned promise rejects |
+| Non-iterable input (e.g., `undefined`) | Returned promise rejects with `TypeError` | Returned promise rejects with `TypeError` |
+| Result order vs resolution order | Results array preserves **input** order, not the order they resolved | Results array preserves **input** order |
+
+> [!NOTE] Two behaviors are commonly misremembered: `Promise.all([])` does not reject or hang. It resolves with an empty array (synchronously, when the iterable is empty; asynchronously otherwise). And the result array always preserves input order, even when `promise[2]` resolves before `promise[0]`.
+
+## Predict the output
+
+### Concurrent vs sequential awaits
+
+These two snippets look almost identical but run very differently:
+
+```js live
+const slow = (label, ms) =>
+  new Promise((resolve) => setTimeout(() => resolve(label), ms));
+
+(async () => {
+  console.time('parallel');
+  const a = await Promise.all([slow('A', 300), slow('B', 300)]);
+  console.timeEnd('parallel'); // ~300ms: both ran concurrently
+
+  console.time('sequential');
+  const b = [await slow('A', 300), await slow('B', 300)];
+  console.timeEnd('sequential'); // ~600ms: second await waits for the first
+})();
+```
+
+`Promise.all()` accepts already-running promises and waits for the slowest. `[await ..., await ...]` evaluates left-to-right and only kicks off the next call after the previous one resolves. The latter is one of the most common production performance bugs.
+
+### `Promise.allSettled()` does not reject on per-promise failures
+
+```js live
+(async () => {
+  const results = await Promise.allSettled([
+    Promise.resolve(1),
+    Promise.reject(new Error('boom')),
+    Promise.resolve(3),
+  ]);
+
+  console.log(results.map((r) => r.status));
+  // ['fulfilled', 'rejected', 'fulfilled']
+
+  // The outer await never throws for inner rejections, so this line still runs:
+  console.log('still here');
+})();
+```
+
+You will almost never put `Promise.allSettled()` inside a `try/catch` for the inner promises, since it does not throw on their rejections. To check for failures, filter on `status === 'rejected'` after the fact. (The returned promise can still reject if the input itself is invalid — for example, a non-iterable will produce a `TypeError`.)
+
 ## Further reading
 
 - [MDN Web Docs: Promise.all()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/all)
diff --git a/questions/what-are-server-sent-events/en-US.mdx b/questions/what-are-server-sent-events/en-US.mdx
index bdb5b69..ada431b 100644
--- a/questions/what-are-server-sent-events/en-US.mdx
+++ b/questions/what-are-server-sent-events/en-US.mdx
@@ -69,9 +69,9 @@ In this example, the server sends a "Hello from server" message initially, and t
 
 ---
 
-## Server-sent events (SSE)
+## What are Server-Sent Events?
 
-Server-sent events (SSE) is a standard that allows a server to push updates to a web client over a single, long-lived HTTP connection. It enables real-time updates without the client having to constantly poll the server for new data.
+Server-Sent Events (SSE) is a standard that allows a server to push updates to a web client over a single, long-lived HTTP connection. It enables real-time updates without the client having to constantly poll the server for new data.
 
 ## How SSE works
 
@@ -187,9 +187,60 @@ http
   });
 ```
 
+## SSE vs WebSockets vs Long Polling
+
+Most interview discussions of SSE start with the WebSockets comparison. To pick the right tool, you also need to know how SSE compares to the older long-polling pattern it largely replaced.
+
+| Property | Long Polling | Server-Sent Events | WebSockets |
+| --- | --- | --- | --- |
+| Direction | Server to client (response per request) | Server to client (one connection, many messages) | Bidirectional |
+| Transport | Plain HTTP | Plain HTTP (`text/event-stream`) | Upgraded TCP (`ws://` or `wss://`) |
+| Reconnect handling | Manual (reissue request) | Built-in (`EventSource` retries automatically) | Manual (write your own backoff) |
+| Message format | Anything (JSON, etc.) | Text only (UTF-8) | Text or binary (frames) |
+| Browser support | Universal | All evergreen browsers | All evergreen browsers |
+| Server cost per connection | Low; connection closes between messages | Moderate; one TCP connection held open per client | Moderate; one TCP connection held open per client |
+| Works through corporate proxies and firewalls | Yes (regular HTTP) | Usually yes (regular HTTP) | Sometimes blocked (`Upgrade: websocket` is rejected by some proxies) |
+| Resume after disconnect | Manual | Built-in via `Last-Event-ID` | Manual |
+
+A useful decision rule:
+
+- For bidirectional, low-latency, frequent client-to-server messages (chat, multiplayer, collaborative editing), use WebSockets.
+- For one-way notifications, dashboards, LLM streaming, or server progress updates, use SSE.
+- To support very old clients or restrictive networks where neither works, fall back to long polling.
+
+## Modern uses of SSE: LLM streaming and beyond
+
+SSE has become a common transport for LLM streaming. The fit is straightforward: completions stream tokens one at a time from server to client, the connection is one-way, and the protocol works over plain HTTPS through most corporate proxies.
+
+- The OpenAI Chat Completions API returns `text/event-stream` when called with `stream: true`. Each `data:` chunk contains a JSON delta with the next token.
+- The Anthropic Messages API uses the same pattern: `text/event-stream` with `data:` chunks per delta.
+- Self-hosted servers like vLLM (which exposes an OpenAI-compatible API) also stream via SSE. Some others (such as Ollama) stream over newline-delimited JSON instead, so check the API docs before assuming SSE.
+
+Beyond AI, SSE fits most "server has new data, push it to the user" use cases:
+
+- Live notifications such as new messages, mentions, and alerts.
+- Long-running job progress (deploys, exports, batch processing), where the server emits progress events as work proceeds.
+- Live status pages and dashboards for build status or server health.
+- Stock tickers and sports scores, where the client does not push data back.
+
+When the use case is "client subscribes, server sends updates", SSE is usually simpler than WebSockets: you get auto-reconnect, message IDs, and HTTP/2 multiplexing for free.
+
+## Production gotchas with SSE
+
+A few practical issues to be aware of:
+
+- **HTTP/1.1 connection limits.** Browsers cap concurrent connections per origin to roughly 6 over HTTP/1.1. A tab that opens an SSE stream and also makes regular API calls can hit the limit quickly, especially when the user opens multiple tabs (each tab opens its own SSE). Running over HTTP/2 or HTTP/3 multiplexes streams over a single connection (typically up to 100 concurrent streams by default), avoiding the per-origin limit.
+- **Buffering proxies break streaming.** Nginx, AWS ALB, and many reverse proxies buffer responses by default, so `data:` chunks accumulate on the proxy and arrive in one large piece. Disable buffering on SSE routes:
+  - Nginx: send `X-Accel-Buffering: no` from the server, or set `proxy_buffering off` in the location block.
+  - AWS ALB: response buffering is generally on; send data more frequently or use API Gateway with HTTP integration.
+  - Cloudflare: usually streams correctly, but check that the route is not behind "Auto Minify" or response transformations.
+- **`Last-Event-ID` on reconnect.** When `EventSource` reconnects after a drop, it sends the last `id:` it received in a `Last-Event-ID` request header. The server should use this to resume from the right point. Otherwise, reconnects either replay everything (causing duplicates) or skip events the client missed.
+- **Authentication.** `EventSource` does not let you set custom request headers, so there is no `Authorization` header. Common workarounds: pass the token as a query string parameter (be careful, since this is visible in server logs), or use cookie-based auth (which `EventSource` does send). The newer `fetch` + `ReadableStream` approach lets you set headers if you need them.
+- **Server timeouts.** Many platforms (Heroku, App Engine, AWS Lambda via API Gateway) cap request duration. SSE connections can last for hours, which exceeds those limits. Either run on a platform that supports long-lived connections (Fly.io, Render, a self-hosted VPS) or have the client reconnect periodically.
+
 ## Summary
 
-Server-sent events provide an efficient and straightforward way to push updates from a server to a client in real-time. They are particularly well-suited for applications that require continuous data streams but do not need full bidirectional communication. With built-in support in modern browsers, SSE is a reliable choice for many real-time web applications.
+Server-sent events provide an efficient and straightforward way to push updates from a server to a client in real-time. They are well-suited for applications that require continuous data streams but do not need full bidirectional communication, including the common pattern of streaming LLM responses. With built-in support in modern browsers, SSE is a reliable choice for many real-time web applications.
 
 ## Further reading
 
diff --git a/questions/what-are-some-of-the-advantages-disadvantages-of-writing-javascript-code-in-a-language-that-compiles-to-javascript/en-US.mdx b/questions/what-are-some-of-the-advantages-disadvantages-of-writing-javascript-code-in-a-language-that-compiles-to-javascript/en-US.mdx
index 18c0a81..101c755 100644
--- a/questions/what-are-some-of-the-advantages-disadvantages-of-writing-javascript-code-in-a-language-that-compiles-to-javascript/en-US.mdx
+++ b/questions/what-are-some-of-the-advantages-disadvantages-of-writing-javascript-code-in-a-language-that-compiles-to-javascript/en-US.mdx
@@ -1,10 +1,10 @@
 ---
-title: What are some of the advantages/disadvantages of writing JavaScript code in a language that compiles to JavaScript?
+title: What are some of the advantages and disadvantages of using TypeScript and compile-to-JavaScript languages
 ---
 
 ## TL;DR
 
-Using languages that compile to JavaScript, like TypeScript or CoffeeScript, can offer several advantages such as improved syntax, type safety, and better tooling. However, they also come with disadvantages like added build steps, potential performance overhead, and the need to learn new syntax.
+Using languages that compile to JavaScript (most commonly TypeScript today, but historically also CoffeeScript, ReScript, Elm, and ClojureScript) can offer several advantages such as improved syntax, type safety, and better tooling. However, they also come with disadvantages like added build steps, potential performance overhead, and the need to learn new syntax.
 
 Advantages:
 
@@ -20,6 +20,22 @@ Disadvantages:
 
 ---
 
+## The compile-to-JavaScript landscape today
+
+The category has consolidated significantly. A few options dominate; most others are now niche or abandoned.
+
+| Language | Current status | What it offers | When to consider |
+| --- | --- | --- | --- |
+| TypeScript | Dominant. The default for most new front-end projects. | Static types, structural typing, mature tooling | Almost any non-trivial project |
+| JSDoc-typed JavaScript | Active alternative to TypeScript (notably adopted by the Svelte compiler) | TypeScript-powered type checking with no build step; types live in comments | Libraries that want zero-build distribution; small projects |
+| ReScript (formerly BuckleScript) | Niche but stable | ML-style type system, fast compiler, sound types | Teams coming from OCaml; data-heavy apps |
+| Elm | Niche, web-only | Pure functional, "no runtime exceptions" guarantee | Small teams that fully commit to its model |
+| ClojureScript | Niche, used by Lisp/Clojure shops | Lisp on the front-end, immutable data, REPL-driven development | Existing Clojure ecosystems |
+| CoffeeScript | Legacy and effectively abandoned | Ruby-flavored syntax | Maintenance only; not for new projects |
+| PureScript | Niche academic | Haskell-like, sound types | Functional-purist teams |
+
+In practice, the decision is almost always between TypeScript (when you want types and a compile step) and JSDoc-typed JavaScript (when you want types without a compile step). Anything else is a deliberate, ecosystem-specific choice.
+
 ## Advantages of writing JavaScript code in a language that compiles to JavaScript
 
 ### Improved syntax and readability
diff --git a/questions/what-are-the-advantages-and-disadvantages-of-using-ajax/en-US.mdx b/questions/what-are-the-advantages-and-disadvantages-of-using-ajax/en-US.mdx
index 634697a..7194f66 100644
--- a/questions/what-are-the-advantages-and-disadvantages-of-using-ajax/en-US.mdx
+++ b/questions/what-are-the-advantages-and-disadvantages-of-using-ajax/en-US.mdx
@@ -47,6 +47,74 @@ Here's a breakdown of AJAX's pros and cons:
 
 While AJAX offers significant advantages in terms of user experience, performance, and functionality, it also introduces complexities and potential drawbacks related to development, SEO, browser compatibility, security, and navigation.
 
+## Is AJAX still relevant today?
+
+Mostly as a historical term. The technique it described, fetching data without a page reload, is now the universal default. The original technology stack (`XMLHttpRequest`, XML payloads, callback-based code) has been replaced almost everywhere.
+
+Here is what changed:
+
+|  | Original AJAX (~2005) | Modern equivalent |
+| --- | --- | --- |
+| Transport API | `XMLHttpRequest` | `fetch()` |
+| Async style | Callbacks | `async`/`await` over Promises |
+| Payload format | XML (`responseXML`) | JSON (almost always) |
+| Cross-origin | Forbidden by same-origin policy; required JSONP hacks | Solved by CORS |
+| SEO of dynamic content | A real problem (Google couldn't index) | Addressed by SSR, SSG, RSC; Googlebot also runs JavaScript |
+| Browser inconsistency | Required wrapper libraries (jQuery `$.ajax`) | All evergreen browsers ship the same `fetch` API |
+
+The pattern AJAX introduced is alive: async data loading without a full page reload is now the default expectation. The underlying technology has moved on.
+
+Using "AJAX" today to mean "we make a `fetch` call from JavaScript" is loose but generally fine. Reaching for `XMLHttpRequest` for new code, on the other hand, is a red flag, since `fetch` is the modern API.
+
+## The modern equivalent: `fetch()` with async/await
+
+Side-by-side, classic AJAX vs current best practice:
+
+```js
+// Classic XHR (~2005-style)
+const xhr = new XMLHttpRequest();
+xhr.open('GET', '/api/users');
+xhr.onreadystatechange = function () {
+  if (xhr.readyState === 4 && xhr.status === 200) {
+    const users = JSON.parse(xhr.responseText);
+    render(users);
+  } else if (xhr.readyState === 4) {
+    showError();
+  }
+};
+xhr.onerror = function () {
+  showError();
+};
+xhr.send();
+```
+
+```js
+// Modern fetch + async/await
+async function loadUsers() {
+  try {
+    const res = await fetch('/api/users');
+    if (!res.ok) throw new Error(`HTTP ${res.status}`);
+    const users = await res.json();
+    render(users);
+  } catch (err) {
+    showError(err);
+  }
+}
+```
+
+The modern version is shorter, easier to read, and composes naturally with `Promise.all`, `AbortController` for cancellation, and libraries like React Query and SWR for caching and deduplication. The remaining reason some teams still use `XMLHttpRequest` is to track upload progress with the `xhr.upload.onprogress` event, since `fetch` upload-progress reporting is more limited. Streaming a `ReadableStream` request body in `fetch` (which would let you build progress on top) is supported in Chromium (since Chrome 105) and Safari (since 18.2), but not yet in Firefox; it also requires the `duplex: 'half'` option on the request.
+
+## Re-examining the disadvantages
+
+Several disadvantages historically listed for AJAX are no longer real concerns in modern apps:
+
+- **SEO challenges**: Googlebot has rendered JavaScript since around 2015, and modern frameworks ship SSR (Next.js, Nuxt, Remix), SSG (Astro, 11ty), or React Server Components for content that needs to be indexable. The AJAX-era SEO problem is largely solved if you choose your rendering strategy intentionally.
+- **Bookmarking and back-button issues**: the History API (`pushState`, `popState`) and modern routers (Next.js, React Router, Vue Router) handle URL state automatically. AJAX-era apps that broke the back button were generally not using these.
+- **Browser support**: `fetch` is in every evergreen browser (Chrome, Firefox, Safari, Edge). Internet Explorer is end-of-life, and the browser-compatibility argument no longer applies.
+- **Reliance on JavaScript**: a tiny minority of users have JavaScript disabled, and modern apps generally assume JavaScript anyway. If you need a no-JS fallback, you build a server-rendered version (which RSC and progressive enhancement support directly).
+
+The disadvantages that genuinely remain are about complexity and security: race conditions and stale state, error handling in async code, XSS via `innerHTML` from API responses, and the ongoing complexity of state management. These are real, but they are problems of any client-side data fetching, not specifically of AJAX.
+
 ## Further reading
 
 - [Ajax | MDN](https://developer.mozilla.org/en-US/docs/Glossary/AJAX)
diff --git a/questions/what-is-use-strict-what-are-the-advantages-and-disadvantages-to-using-it/en-US.mdx b/questions/what-is-use-strict-what-are-the-advantages-and-disadvantages-to-using-it/en-US.mdx
index 2e73b9d..666c522 100644
--- a/questions/what-is-use-strict-what-are-the-advantages-and-disadvantages-to-using-it/en-US.mdx
+++ b/questions/what-is-use-strict-what-are-the-advantages-and-disadvantages-to-using-it/en-US.mdx
@@ -1,5 +1,5 @@
 ---
-title: What is `'use strict';` in JavaScript for?
+title: What is `'use strict';` (strict mode) in JavaScript for?
 subtitle: What are the advantages and disadvantages to using it?
 ---
 
@@ -119,14 +119,98 @@ When you use `"use strict"`, it helps you write cleaner code, such as preventing
    delete Object.prototype; // TypeError: Cannot delete property 'prototype' of function Object() { [native code] }
    ```
 
-## Is it "strictly" necessary?
+## Predict the output: common strict mode gotchas
 
-Adding `'use strict'` in JavaScript is still beneficial and recommended, but it is no longer strictly necessary in all cases:
+These are the four most common interview "gotchas" around strict mode. Try predicting the output before running each.
 
-1. **Modules**: The entire contents of JavaScript modules are automatically in strict mode, without needing the `'use strict'` statement. This applies to ES6 modules as well as Node.js CommonJS modules.
-2. **Classes**: Code within class definitions is also automatically in strict mode, even without `'use strict'`.
+### 1. Accidental globals
 
-While `'use strict'` is no longer mandatory in all contexts due to the automatic strict mode enforcement in modules and classes, it is still widely recommended as a best practice, especially for core JavaScript files, libraries, and when working with older browser environments or legacy code.
+```js live
+function f() {
+  x = 5; // no var/let/const, assignment to undeclared variable
+}
+f();
+console.log(x); // 5: sloppy mode silently created a global
+```
+
+In strict mode, that same code throws a `ReferenceError` because creating implicit globals is forbidden. This is the single most-cited reason to use strict mode.
+
+```js live
+'use strict';
+function f() {
+  x = 5; // ReferenceError: x is not defined
+}
+try {
+  f();
+} catch (e) {
+  console.log(e.message);
+}
+```
+
+### 2. `this` in a plain function call
+
+```js live
+function whatIsThis() {
+  return this;
+}
+console.log(whatIsThis() === globalThis); // true in sloppy mode
+```
+
+In strict mode, `this` inside a function called as a plain function is `undefined`:
+
+```js live
+'use strict';
+function whatIsThis() {
+  return this;
+}
+console.log(whatIsThis()); // undefined
+```
+
+This is a common source of bugs in class methods that get extracted as callbacks. `const fn = obj.method; fn();` calls `method` with `this === undefined`, which usually crashes immediately. In sloppy mode, the same call would silently bind `this` to the global object and continue with broken behavior.
+
+### 3. Duplicate parameter names
+
+```js live
+'use strict';
+try {
+  // Using eval to force a parse error to be thrown at runtime in strict mode
+  eval('function dup(a, a) {}');
+} catch (e) {
+  console.log(e.message); // "Duplicate parameter name not allowed in this context"
+}
+```
+
+In sloppy mode, `function f(a, a) {}` is silently allowed and the second `a` shadows the first.
+
+### 4. Octal literals
+
+```js live
+console.log(010); // 8 in sloppy mode (leading 0 means octal)
+```
+
+In strict mode (and in ES modules), the legacy `0`-prefix octal literal is rejected at parse time. Use the explicit `0o` prefix instead:
+
+```js
+'use strict';
+console.log(0o10); // 8
+```
+
+## Is `'use strict'` still necessary?
+
+In most modern code, no. Strict mode is now the default in several places:
+
+- **ES modules** are automatically strict. Anything imported with `import`/`export`, served as `<script type="module">`, or compiled by Vite, webpack, or Rollup runs in strict mode without the directive.
+- **Class bodies** (and methods inside them) are strict, even when the surrounding code is not.
+- **Most build tools** (Babel, TypeScript with `target: ES2015+`) emit code that is either modules or class-wrapped, so it is strict by default.
+
+The directive still matters in a few places:
+
+- Legacy plain `<script>` tags without `type="module"`. The directive is the only way to opt in.
+- IIFEs and old library bundles that ship as scripts, including some CDN copies of libraries.
+- Node.js CommonJS files (`.cjs`), which are not automatically strict.
+- Quick `<script>` snippets in HTML pages and CodePens.
+
+If you are writing an ES module or a React/Vue component, you are already in strict mode and the directive at the top of the file is harmless but redundant. If you are writing a plain `<script>` tag without `type="module"`, you should still add it.
 
 ### Notes
 
diff --git a/questions/whats-the-difference-between-an-attribute-and-a-property/en-US.mdx b/questions/whats-the-difference-between-an-attribute-and-a-property/en-US.mdx
index 35ccf4c..9fccc9c 100644
--- a/questions/whats-the-difference-between-an-attribute-and-a-property/en-US.mdx
+++ b/questions/whats-the-difference-between-an-attribute-and-a-property/en-US.mdx
@@ -65,6 +65,121 @@ console.log(inputElement.getAttribute('value')); // "initial value"
 
 In this example, changing the `value` property does not affect the `value` attribute.
 
+## The classic example: input value (try it live)
+
+This is the canonical interview demonstration. Open the input below, type into it, and watch how the **attribute** stays at the initial value while the **property** tracks what the user typed:
+
+```js live
+document.body.innerHTML = `
+  <input id="demo" type="text" value="initial value" />
+  <button id="check">Log attribute vs property</button>
+  <pre id="out"></pre>
+`;
+
+const input = document.getElementById('demo');
+const out = document.getElementById('out');
+
+document.getElementById('check').addEventListener('click', () => {
+  out.textContent =
+    `attribute (getAttribute('value')): ${input.getAttribute('value')}\n` +
+    `property  (input.value):           ${input.value}`;
+});
+
+// Programmatic demo if no user typing happens:
+input.value = 'typed by user';
+out.textContent =
+  `attribute (getAttribute('value')): ${input.getAttribute('value')}\n` +
+  `property  (input.value):           ${input.value}`;
+```
+
+The takeaway: **the attribute is the original markup; the property is the current state**. They diverge the moment the user (or your code) interacts with the element.
+
+To **reset** an input back to its attribute, set the property back to the attribute value (`input.value = input.defaultValue`). To **persist** a new initial value across resets, you have to set the attribute too (`input.setAttribute('value', '...')` or `input.defaultValue = '...'`).
+
+## Other attributes that diverge from their properties
+
+The `value` attribute is the most-cited example, but several other attributes have a meaningfully different DOM property. Each of these comes up regularly in real bugs.
+
+### `checked` on checkboxes and radios
+
+```js live
+document.body.innerHTML = `<input type="checkbox" id="cb" checked />`;
+const cb = document.getElementById('cb');
+
+console.log(cb.getAttribute('checked')); // "" (present in markup)
+console.log(cb.checked); // true
+
+cb.checked = false; // user un-checks (or your code does)
+console.log(cb.getAttribute('checked')); // still "" (attribute did not change)
+console.log(cb.checked); // false
+```
+
+Same pattern: the attribute is the **default** state used on form reset; the property is the **current** state.
+
+### `disabled` on inputs and buttons
+
+```js live
+document.body.innerHTML = `<button id="b">Submit</button>`;
+const b = document.getElementById('b');
+
+b.setAttribute('disabled', 'disabled'); // sets the attribute
+console.log(b.disabled); // true (property reflects the attribute)
+
+b.disabled = false; // sets the property
+console.log(b.getAttribute('disabled')); // null (attribute is removed)
+```
+
+Boolean attributes like `disabled`, `readonly`, `required`, and `hidden` are **reflected**: setting the property automatically adds or removes the attribute. This is different from `value`/`checked`, where the attribute stays put.
+
+### `class` (attribute) vs `className` and `classList` (properties)
+
+```js live
+document.body.innerHTML = `<div id="d" class="a b c"></div>`;
+const d = document.getElementById('d');
+
+console.log(d.getAttribute('class')); // "a b c"
+console.log(d.className); // "a b c" (same string)
+console.log(d.classList); // DOMTokenList ['a', 'b', 'c']
+
+d.classList.add('d');
+console.log(d.getAttribute('class')); // "a b c d"
+```
+
+The attribute is `class`; the DOM property is `className` (because `class` is a reserved word in JavaScript). The modern `classList` API gives you `add`/`remove`/`toggle` methods that update both for you.
+
+### `for` (attribute) vs `htmlFor` (property)
+
+The `for` attribute on a `<label>` becomes the `htmlFor` property, for the same reason (`for` is a reserved word in JavaScript). This is a common stumbling block for React developers because JSX uses `htmlFor`:
+
+```jsx
+// React JSX uses the property name
+<label htmlFor="email">Email</label>;
+
+// Plain HTML uses the attribute name
+<label for="email">Email</label>;
+```
+
+### `style`: string vs object
+
+The `style` attribute is a string. The `style` property is a `CSSStyleDeclaration` object:
+
+```js
+element.getAttribute('style'); // 'color: red; font-size: 14px' (string)
+element.style; // CSSStyleDeclaration object; element.style.color === 'red'
+```
+
+You read individual rules from the property (`element.style.fontSize`) but cannot read computed values that way. For computed styles, use `getComputedStyle(element).fontSize`.
+
+## Why this matters in React, Vue, and other frameworks
+
+Frameworks set properties in some places and attributes in others, and knowing which they choose explains a class of "this attribute won't update" bugs.
+
+- **React** sets DOM properties when a matching one exists, so `<input value={x}>` updates the property, not the attribute. This is why `defaultValue` exists: it is the way to set the underlying attribute. The same pattern applies to `defaultChecked` on checkboxes.
+- **Vue 3** intelligently chooses between property and attribute for each binding. For standard interactive elements (such as `value` on `<input>`, `<select>`, and `<progress>`), it sets the DOM property. You can force one or the other with the `.prop` and `.attr` modifiers on `v-bind`.
+- **Custom elements** declared with attributes need `attributeChangedCallback` and `observedAttributes` to react to attribute changes. Properties do not go through that path.
+
+If you ever see a React form where setting `<input value={state}>` works fine, but inspecting the rendered DOM shows the `value="..."` attribute stuck at the old value, that is not a bug. The attribute is intentionally the initial-value marker; the property is what reflects the live state.
+
 ## Further reading
 
 - [MDN Web Docs: Element.getAttribute()](https://developer.mozilla.org/en-US/docs/Web/API/Element/getAttribute)