From 0aba94505fccbd8bcf5474d4b4ed44464f7f8f24 Mon Sep 17 00:00:00 2001
From: Faustze <baros24@mail.ru>
Date: Fri, 24 Jul 2026 16:40:56 +0300
Subject: [PATCH] chore: remove stale content/browser/Event Loop/ leftover
 files
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

An earlier sync (before the Obsidian-Vault itself was flattened) had
recreated this nested folder in content/. sync-obsidian-notes.sh only
copies/overwrites from the vault — it never prunes files that no longer
exist there — so these stale duplicates of Rendering Pipeline.md,
Event Loop, Microtasks, Macrotasks.md and index.md kept shipping to the
live site even after the vault was fixed and re-synced.
---
 content-ru/.translation-manifest.json         |   2 +-
 .../Event Loop, Microtasks, Macrotasks.md     |  88 --------------
 .../browser/Event Loop/Rendering Pipeline.md  | 107 ------------------
 content/browser/Event Loop/index.md           |  12 --
 4 files changed, 1 insertion(+), 208 deletions(-)
 delete mode 100644 content/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md
 delete mode 100644 content/browser/Event Loop/Rendering Pipeline.md
 delete mode 100644 content/browser/Event Loop/index.md

diff --git a/content-ru/.translation-manifest.json b/content-ru/.translation-manifest.json
index 3f98e86edaf8..d230994aee12 100644
--- a/content-ru/.translation-manifest.json
+++ b/content-ru/.translation-manifest.json
@@ -96,8 +96,8 @@
   "leetcode/Untagged/2726-calculator-with-method-chaining.md": "249ec94bdb2fa52ded25c266daf411ed4e208d966f0041939aabe4d647d99c7f",
   "leetcode/Untagged/index.md": "988a5773fd5f501cd92b5b3223500966941b19d5f2d21448da391cdc4895f064",
   "leetcode/index.md": "88c151c7c5564227dea91e47d96076632d854dd7fc1eddfa45440093be401dc3",
-  "vue/Internals/Compiler.md": "c46b3dd12912b11bc4f0a34b2abba574baff9626f42df410eab279ae77b99e90",
   "vue/Internals/Reactivity.md": "9b502f513195b4512f4d8188f1ac30746030e1c5a52a6a626d51c80c15752d24",
+  "vue/Internals/Compiler.md": "c46b3dd12912b11bc4f0a34b2abba574baff9626f42df410eab279ae77b99e90",
   "vue/Internals/index.md": "0637645f58c346554c1687702236afa74ed3b25e795a4c0ad5038369ed0479fb",
   "vue/index.md": "aa6244e7ef392b574ddd86f1cafeeac49e03dda7df6eb83b1767e493d1059669"
 }
diff --git a/content/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md b/content/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md
deleted file mode 100644
index f56fe5af4d00..000000000000
--- a/content/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md	
+++ /dev/null
@@ -1,88 +0,0 @@
-# ⏱ Event Loop, Microtasks, Macrotasks, requestAnimationFrame
-
-## 💡 Core idea
-
-> The Event Loop doesn't execute code. It's a dispatcher: it checks whether the call stack is empty, then moves the next queued task into it.
-
-Two questions this note answers: why does `setTimeout(fn, 0)` always run after all synchronous code *and* all promises? And why does an infinite `Promise.then()` chain freeze the tab dead, while an infinite `requestAnimationFrame` loop doesn't?
-
----
-# 🧭 The participants
-
-1. **Call Stack** — runs synchronous JS line by line. Nothing else runs while it isn't empty.
-2. **JS engine (V8, etc.)** — executes only the call stack. It has no built-in concept of `setTimeout`, the DOM, or `fetch` — none of that is part of the ECMAScript spec.
-3. **Web APIs** (browser) / **libuv** (Node.js) — a separate part of the runtime that actually counts timers, listens for network/DOM events, and prepares frames.
-4. **Macrotask queue** — `setTimeout`, `setInterval`, DOM events, I/O. FIFO; the Event Loop pulls **one task at a time** from it.
-5. **Microtask queue** — `Promise.then`, `queueMicrotask`, `MutationObserver`. FIFO, but the Event Loop **drains it completely** before doing anything else.
-6. **Event Loop** — the dispatcher itself: in a loop, it checks "is the call stack empty?", pulls the next task, pushes it onto the stack.
-
----
-# 🔑 The golden rule
-
-> After every synchronous task, the Event Loop **fully drains** the microtask queue — including microtasks added while draining is in progress. Only once the queue is empty does it move on (to rendering, or to a single macrotask).
-
-The difference isn't "priority" — it's a different draining strategy: microtasks mean *"finish everything that has piled up, however much that turns out to be"*; a macrotask means *"take exactly one thing and hand control back to the dispatcher"*.
-
-**One full loop iteration:**
-
-```
-Call Stack (all synchronous code)
-  → drain microtask queue COMPLETELY (even if it refills while draining)
-      → requestAnimationFrame callbacks (a snapshot of exactly this frame)
-          → Render: Layout → Paint → Composite
-              → take ONE macrotask → run it
-                  → drain microtask queue again
-                      → ... repeat
-```
-
----
-# 🎞 requestAnimationFrame
-
-`requestAnimationFrame(cb)` asks the browser to *"run this right before the next frame is painted"*. It's not a timer and gives no guarantee about exact milliseconds — it's tied to the actual screen refresh cycle (~60/sec).
-
-Ordering, with rAF in the mix:
-
-```js
-Promise.resolve().then(() => console.log('promise'));
-requestAnimationFrame(() => console.log('raf'));
-setTimeout(() => console.log('timeout'), 0);
-
-// promise → raf → timeout
-```
-
----
-# ❄️ Why infinite Promise.then() freezes the tab, but infinite rAF doesn't
-
-Not a coincidence — the two queues work on fundamentally different mechanics.
-
-**The microtask queue is checked dynamically.** Before every step, the Event Loop asks "is the queue empty?". If the microtask currently running enqueues a new one, that new one joins the queue and runs **in this same pass**. For an infinite chain, the exit condition ("empty") never arrives:
-
-```js
-function loop() {
-  Promise.resolve().then(loop); // every .then() spawns the next one
-}
-loop();
-// the Event Loop never reaches rendering, macrotasks, or clicks — the tab is dead
-```
-
-**The rAF queue for a frame is a snapshot (batch), fixed at the start of that frame's processing.** Anything registered via `requestAnimationFrame(...)` *during* the current batch's execution physically cannot land in that same batch — only in the next frame:
-
-```js
-function animate() {
-  x++;
-  requestAnimationFrame(animate); // goes into the NEXT frame, not this one
-}
-requestAnimationFrame(animate);
-// Render (Layout → Paint → Composite) is guaranteed to happen between frames
-```
-
-So infinite recursion through rAF doesn't block the browser: a render always lands between iterations. The key distinction isn't about how fast either callback runs — it's that the microtask queue has no snapshot boundary, and the rAF batch does.
-
----
-# 🧠 In one sentence
-
-> The Event Loop's exit condition for the microtask queue is "empty" — a self-refilling queue never reaches it. The rAF queue instead exits by *snapshot*: what gets added during a batch is deferred to the next one no matter how fast it runs.
-
-[[browser/Event Loop/index|Event Loop & Rendering]]
-[[browser/Event Loop/Rendering Pipeline|Rendering Pipeline — what happens after the microtask queue drains]]
-#browser
diff --git a/content/browser/Event Loop/Rendering Pipeline.md b/content/browser/Event Loop/Rendering Pipeline.md
deleted file mode 100644
index 73b162cbbe9c..000000000000
--- a/content/browser/Event Loop/Rendering Pipeline.md	
+++ /dev/null
@@ -1,107 +0,0 @@
-# 🖼 Rendering Pipeline: Parse → Style → Layout → Paint → Composite
-
-## 💡 Core idea
-
-> Not every style change is equally expensive. What a CSS property triggers — Layout, Paint, or just Composite — decides whether an animation runs smoothly or drops frames.
-
----
-# 🧭 The full pipeline
-
-```
-Parse HTML → DOM
-Parse CSS  → CSSOM
-DOM + CSSOM → Render Tree (excludes display:none)
-Render Tree → Layout      (geometry: x, y, width, height)
-Layout      → Paint       (pixels: color, text, shadows)
-Paint       → Composite   (GPU assembles layers)
-```
-
-`element.style.width = '100px'` does **not** trigger layout immediately. The browser just flags the element (and often its subtree) as "dirty" and defers the recalculation to the next natural render point — the step that sits right after the microtask queue drains and rAF callbacks run in the [[browser/Event Loop/Event Loop|Event Loop]].
-
-Important distinction: **CSSOM** (parsed rules from `<style>`/stylesheets) and inline `element.style` (a `CSSStyleDeclaration` object tied to one element's `style` attribute) are separate objects. Writing `el.style.width = ...` never touches CSSOM — it only dirties that one element.
-
----
-# ⚡ What triggers each stage
-
-```
-Layout:          width/height, top/left/right/bottom, margin/padding,
-                  border-width, font-size, display, adding/removing DOM nodes
-Paint:            color, background, box-shadow, border-radius, visibility, outline
-Composite-only:   transform, opacity
-```
-
-## Why transform/opacity are cheap
-
-Not because of what the properties *mean* — because of *where* they're processed. If an element already has its own compositor layer (a GPU texture — from `will-change`, a running animation, `position: fixed`, `<video>`, `<canvas>`, etc.), changing `transform`/`opacity` is just applying a transform matrix or an alpha value to an *already-rasterized* texture, entirely on the **compositor thread**. Layout and Paint don't run at all.
-
-- `transform` isn't a category of "animation properties" — it's geometric transforms (translate/scale/rotate/skew/matrix) that happen to be cheap to animate.
-- `opacity` isn't brightness — it's the alpha channel (0 = invisible, 1 = opaque).
-
-All `transform` functions compile down to one canonical form:
-
-- `translate(x, y)` — shift along axes (`translateX/Y/Z`, `translate3d`)
-- `scale(x, y)` — resize (`scale(1.5)` = 1.5× bigger); `scaleX`/`scaleY` independently per axis
-- `rotate(angle)` — rotation around a point (default: element center); `rotateX/Y/Z` for 3D
-- `skew(x-angle, y-angle)` — shear: turns a rectangle into a parallelogram
-- `matrix(a, b, c, d, e, f)` — the low-level 2×3 affine matrix all of the above compile to (`matrix3d` — 4×4, for 3D)
-
----
-# 🧵 Main thread vs Compositor thread
-
-```
-Main thread:        JS execution → Style calc → Layout → Paint
-Compositor thread:  Composite (transform/opacity)
-```
-
-The main thread is where the [[browser/Event Loop/Event Loop|Event Loop]], the call stack, and all JS run — Style, Layout and Paint live there too. If the main thread is blocked (long synchronous JS, forced reflow), everything stalls: scrolling, clicks, and any animation on `width`/`top`.
-
-The compositor thread is separate and isn't blocked by the main thread. By the time Composite runs, DOM/CSSOM no longer matter: Paint (on the main thread) has already turned the element into a rasterized GPU texture. The compositor thread only ever sees finished textures and transform matrices — it never touches the DOM tree. Composite isn't "drawing over an HTML/CSS skeleton" — it's "place already-finished images on screen".
-
-## How compositor layers form
-
-A layer is not a DOM element — it's a region of pixels plus a rule for positioning it. It's made of:
-
-- a **display list** — Paint's recorded drawing commands ("fill this rectangle", "draw this text") for the part of the DOM in that layer
-- a **rasterized texture (bitmap)** — the result of executing the display list, usually cut into **tiles** (e.g. 256×256px) for efficient re-upload
-- **transform properties** — the matrix (transform), opacity, and position in the compositor's coordinate system
-
-Formation steps:
-
-1. **Style** — CSS values are computed
-2. **Layout** — geometry is computed (sizes, positions)
-3. **Layer tree construction (layerization)** — the main thread decides which elements get their own compositor layer. Triggers: animated `transform`/`opacity`, `will-change`, `position: fixed`, `<video>`, `<canvas>`. Everything else paints into its parent's layer.
-4. **Paint** — the main thread doesn't draw pixels, it records a display list per layer
-5. **Rasterization** — the display list becomes actual pixels, usually via GPU (e.g. Skia's GPU backend), often on separate raster threads
-6. **Compositing** — the compositor thread assembles the finished layer textures into the final frame, applying each layer's transform/opacity as a whole
-
-Steps 1–4 run on the main thread; steps 5–6 run on separate threads. If only `transform`/`opacity` changes on an element that already has a layer, steps 1–4 are skipped entirely — straight to step 6 with the existing texture.
-
-Why render each layer into its own texture: it can be reused without repainting. If a layer already holds something expensive (text, shadows, gradients) and it's just being moved (`translateX`), there's no need to re-run the drawing commands — the GPU just repositions the finished texture. It also parallelizes: different layers rasterize on different threads simultaneously, and only the layer that actually changed gets repainted.
-
----
-# 🐢 Forced synchronous layout
-
-If you write a style and immediately read a layout-dependent property (`offsetWidth`, `getBoundingClientRect()`, `clientHeight`, `scrollTop`, …), the browser must recompute geometry **synchronously, right there** to give an accurate answer — it can't defer to the next render point.
-
-```js
-// bad: 1000 forced layouts, one per iteration
-items.forEach(item => {
-  item.style.width = '100px';       // write — flags the element dirty
-  console.log(item.offsetWidth);    // read — forces a full recalculation NOW
-});
-
-// good: one layout for the whole batch
-items.forEach(item => { item.style.width = '100px'; });    // all writes first
-items.forEach(item => { console.log(item.offsetWidth); }); // all reads — first read recomputes, the rest hit the cache
-```
-
-Why this is expensive: layout doesn't just compute geometry for the touched element — usually for a large affected part of the tree (elements influence each other through flexbox, percentages, text reflow). It's like re-measuring 1000 walls and calling the inspector after each one, instead of calling them once at the end.
-
----
-# 🧠 In one sentence
-
-> `width`/`top` changes cost Layout + Paint on the main thread; `color`/`shadow` changes cost Paint only; `transform`/`opacity` skip both and stay on the compositor thread — that's the entire reason to prefer animating the latter.
-
-[[browser/Event Loop/index|Event Loop & Rendering]]
-[[browser/Event Loop/Event Loop, Microtasks, Macrotasks|Event Loop — where render fits into the loop]]
-#browser
diff --git a/content/browser/Event Loop/index.md b/content/browser/Event Loop/index.md
deleted file mode 100644
index 0dfdce2a75a5..000000000000
--- a/content/browser/Event Loop/index.md	
+++ /dev/null
@@ -1,12 +0,0 @@
----
-title: event loop
----
-
-# Event Loop & Rendering
-
-[[browser/index|← Browser]]
-
-- [[browser/Event Loop/Event Loop, Microtasks, Macrotasks|Event Loop, Microtasks, Macrotasks]]
-- [[browser/Event Loop/Rendering Pipeline|Rendering Pipeline: Layout, Paint, Composite]]
-
-#browser