From f185d3947b7809afa39bf2099f0ff39f3a20cd50 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sad=C4=B1k=20=C3=9Cnal=20=C3=87ok=C3=BCnl=C3=BC?=
 <retaler_21@hotmail.com>
Date: Sun, 1 Aug 2021 08:41:11 +0300
Subject: [PATCH 1/5] Create article.md

---
 2-ui/99-ui-misc/03-event-loop/article.md | 339 +++++++++++++++++++++++
 1 file changed, 339 insertions(+)
 create mode 100644 2-ui/99-ui-misc/03-event-loop/article.md

diff --git a/2-ui/99-ui-misc/03-event-loop/article.md b/2-ui/99-ui-misc/03-event-loop/article.md
new file mode 100644
index 000000000..3ea0c2c57
--- /dev/null
+++ b/2-ui/99-ui-misc/03-event-loop/article.md
@@ -0,0 +1,339 @@
+
+# Event loop: microtasks and macrotasks
+
+Browser JavaScript execution flow, as well as in Node.js, is based on an *event loop*.
+
+Understanding how event loop works is important for optimizations, and sometimes for the right architecture.
+
+In this chapter we first cover theoretical details about how things work, and then see practical applications of that knowledge.
+
+## Event Loop
+
+The *event loop* concept is very simple. There's an endless loop, where the JavaScript engine waits for tasks, executes them and then sleeps, waiting for more tasks.
+
+The general algorithm of the engine:
+
+1. While there are tasks:
+    - execute them, starting with the oldest task.
+2. Sleep until a task appears, then go to 1.
+
+That's a formalization for what we see when browsing a page. The JavaScript engine does nothing most of the time, it only runs if a script/handler/event activates.
+
+Examples of tasks:
+
+- When an external script `<script src="...">` loads, the task is to execute it.
+- When a user moves their mouse, the task is to dispatch `mousemove` event and execute handlers.
+- When the time is due for a scheduled `setTimeout`, the task is to run its callback.
+- ...and so on.
+
+Tasks are set -- the engine handles them -- then waits for more tasks (while sleeping and consuming close to zero CPU).
+
+It may happen that a task comes while the engine is busy, then it's enqueued.
+
+The tasks form a queue, so-called "macrotask queue" (v8 term):
+
+![](eventLoop.svg)
+
+For instance, while the engine is busy executing a `script`, a user may move their mouse causing `mousemove`, and `setTimeout` may be due and so on, these tasks form a queue, as illustrated on the picture above.
+
+Tasks from the queue are processed on "first come – first served" basis. When the engine browser is done with the `script`, it handles `mousemove` event, then `setTimeout` handler, and so on.
+
+So far, quite simple, right?
+
+Two more details:
+1. Rendering never happens while the engine executes a task. It doesn't matter if the task takes a long time. Changes to the DOM are painted only after the task is complete.
+2. If a task takes too long, the browser can't do other tasks, such as processing user events. So after a time, it raises an alert like "Page Unresponsive", suggesting killing the task with the whole page. That happens when there are a lot of complex calculations or a programming error leading to an infinite loop.
+
+That was the theory. Now let's see how we can apply that knowledge.
+
+## Use-case 1: splitting CPU-hungry tasks
+
+Let's say we have a CPU-hungry task.
+
+For example, syntax-highlighting (used to colorize code examples on this page) is quite CPU-heavy. To highlight the code, it performs the analysis, creates many colored elements, adds them to the document -- for a large amount of text that takes a lot of time.
+
+While the engine is busy with syntax highlighting, it can't do other DOM-related stuff, process user events, etc. It may even cause the browser to "hiccup" or even "hang" for a bit, which is unacceptable.
+
+We can avoid problems by splitting the big task into pieces. Highlight first 100 lines, then schedule `setTimeout` (with zero-delay) for the next 100 lines, and so on.
+
+To demonstrate this approach, for the sake of simplicity, instead of text-highlighting, let's take a function that counts from `1` to `1000000000`.
+
+If you run the code below, the engine will "hang" for some time. For server-side JS that's clearly noticeable, and if you are running it in-browser, then try to click other buttons on the page -- you'll see that no other events get handled until the counting finishes.
+
+```js run
+let i = 0;
+
+let start = Date.now();
+
+function count() {
+
+  // do a heavy job
+  for (let j = 0; j < 1e9; j++) {
+    i++;
+  }
+
+  alert("Done in " + (Date.now() - start) + 'ms');
+}
+
+count();
+```
+
+The browser may even show a "the script takes too long" warning.
+
+Let's split the job using nested `setTimeout` calls:
+
+```js run
+let i = 0;
+
+let start = Date.now();
+
+function count() {
+
+  // do a piece of the heavy job (*)
+  do {
+    i++;
+  } while (i % 1e6 != 0);
+
+  if (i == 1e9) {
+    alert("Done in " + (Date.now() - start) + 'ms');
+  } else {
+    setTimeout(count); // schedule the new call (**)
+  }
+
+}
+
+count();
+```
+
+Now the browser interface is fully functional during the "counting" process.
+
+A single run of `count` does a part of the job `(*)`, and then re-schedules itself `(**)` if needed:
+
+1. First run counts: `i=1...1000000`.
+2. Second run counts: `i=1000001..2000000`.
+3. ...and so on.
+
+Now, if a new side task (e.g. `onclick` event) appears while the engine is busy executing part 1, it gets queued and then executes when part 1 finished, before the next part. Periodic returns to the event loop between `count` executions provide just enough "air" for the JavaScript engine to do something else, to react to other user actions.
+
+The notable thing is that both variants -- with and without splitting the job by `setTimeout` -- are comparable in speed. There's not much difference in the overall counting time.
+
+To make them closer, let's make an improvement.
+
+We'll move the scheduling to the beginning of the `count()`:
+
+```js run
+let i = 0;
+
+let start = Date.now();
+
+function count() {
+
+  // move the scheduling to the beginning
+  if (i < 1e9 - 1e6) {
+    setTimeout(count); // schedule the new call
+  }
+
+  do {
+    i++;
+  } while (i % 1e6 != 0);
+
+  if (i == 1e9) {
+    alert("Done in " + (Date.now() - start) + 'ms');
+  }
+
+}
+
+count();
+```
+
+Now when we start to `count()` and see that we'll need to `count()` more, we schedule that immediately, before doing the job.
+
+If you run it, it's easy to notice that it takes significantly less time.
+
+Why?  
+
+That's simple: as you remember, there's the in-browser minimal delay of 4ms for many nested `setTimeout` calls. Even if we set `0`, it's `4ms` (or a bit more). So the earlier we schedule it - the faster it runs.
+
+Finally, we've split a CPU-hungry task into parts - now it doesn't block the user interface. And its overall execution time isn't much longer.
+
+## Use case 2: progress indication
+
+Another benefit of splitting heavy tasks for browser scripts is that we can show progress indication.
+
+As mentioned earlier, changes to DOM are painted only after the currently running task is completed, irrespective of how long it takes.
+
+On one hand, that's great, because our function may create many elements, add them one-by-one to the document and change their styles -- the visitor won't see any "intermediate", unfinished state. An important thing, right?
+
+Here's the demo, the changes to `i` won't show up until the function finishes, so we'll see only the last value:
+
+
+```html run
+<div id="progress"></div>
+
+<script>
+
+  function count() {
+    for (let i = 0; i < 1e6; i++) {
+      i++;
+      progress.innerHTML = i;
+    }
+  }
+
+  count();
+</script>
+```
+
+...But we also may want to show something during the task, e.g. a progress bar.
+
+If we split the heavy task into pieces using `setTimeout`, then changes are painted out in-between them.
+
+This looks prettier:
+
+```html run
+<div id="progress"></div>
+
+<script>
+  let i = 0;
+
+  function count() {
+
+    // do a piece of the heavy job (*)
+    do {
+      i++;
+      progress.innerHTML = i;
+    } while (i % 1e3 != 0);
+
+    if (i < 1e7) {
+      setTimeout(count);
+    }
+
+  }
+
+  count();
+</script>
+```
+
+Now the `<div>` shows increasing values of `i`, a kind of a progress bar.
+
+
+## Use case 3: doing something after the event
+
+In an event handler we may decide to postpone some actions until the event bubbled up and was handled on all levels. We can do that by wrapping the code in zero delay `setTimeout`.
+
+In the chapter <info:dispatch-events> we saw an example: custom event `menu-open` is dispatched in `setTimeout`, so that it happens after the "click" event is fully handled.
+
+```js
+menu.onclick = function() {
+  // ...
+
+  // create a custom event with the clicked menu item data
+  let customEvent = new CustomEvent("menu-open", {
+    bubbles: true
+  });
+
+  // dispatch the custom event asynchronously
+  setTimeout(() => menu.dispatchEvent(customEvent));
+};
+```
+
+## Macrotasks and Microtasks
+
+Along with *macrotasks*, described in this chapter, there are *microtasks*, mentioned in the chapter <info:microtask-queue>.
+
+Microtasks come solely from our code. They are usually created by promises: an execution of `.then/catch/finally` handler becomes a microtask. Microtasks are used "under the cover" of `await` as well, as it's another form of promise handling.
+
+There's also a special function `queueMicrotask(func)` that queues `func` for execution in the microtask queue.
+
+**Immediately after every *macrotask*, the engine executes all tasks from *microtask* queue, prior to running any other macrotasks or rendering or anything else.**
+
+For instance, take a look:
+
+```js run
+setTimeout(() => alert("timeout"));
+
+Promise.resolve()
+  .then(() => alert("promise"));
+
+alert("code");
+```
+
+What's going to be the order here?
+
+1. `code` shows first, because it's a regular synchronous call.
+2. `promise` shows second, because `.then` passes through the microtask queue, and runs after the current code.
+3. `timeout` shows last, because it's a macrotask.
+
+The richer event loop picture looks like this (order is from top to bottom, that is: the script first, then microtasks, rendering and so on):
+
+![](eventLoop-full.svg)
+
+All microtasks are completed before any other event handling or rendering or any other macrotask takes place.
+
+That's important, as it guarantees that the application environment is basically the same (no mouse coordinate changes, no new network data, etc) between microtasks.
+
+If we'd like to execute a function asynchronously (after the current code), but before changes are rendered or new events handled, we can schedule it with `queueMicrotask`.
+
+Here's an example with "counting progress bar", similar to the one shown previously, but `queueMicrotask` is used instead of `setTimeout`. You can see that it renders at the very end. Just like the synchronous code:
+
+```html run
+<div id="progress"></div>
+
+<script>
+  let i = 0;
+
+  function count() {
+
+    // do a piece of the heavy job (*)
+    do {
+      i++;
+      progress.innerHTML = i;
+    } while (i % 1e3 != 0);
+
+    if (i < 1e6) {
+  *!*
+      queueMicrotask(count);
+  */!*
+    }
+
+  }
+
+  count();
+</script>
+```
+
+## Summary
+
+A more detailed event loop algorithm (though still simplified compared to the [specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)):
+
+1. Dequeue and run the oldest task from the *macrotask* queue (e.g. "script").
+2. Execute all *microtasks*:
+    - While the microtask queue is not empty:
+        - Dequeue and run the oldest microtask.
+3. Render changes if any.
+4. If the macrotask queue is empty, wait till a macrotask appears.
+5. Go to step 1.
+
+To schedule a new *macrotask*:
+- Use zero delayed `setTimeout(f)`.
+
+That may be used to split a big calculation-heavy task into pieces, for the browser to be able to react to user events and show progress between them.
+
+Also, used in event handlers to schedule an action after the event is fully handled (bubbling done).
+
+To schedule a new *microtask*
+- Use `queueMicrotask(f)`.
+- Also promise handlers go through the microtask queue.
+
+There's no UI or network event handling between microtasks: they run immediately one after another.
+
+So one may want to `queueMicrotask` to execute a function asynchronously, but within the environment state.
+
+```smart header="Web Workers"
+For long heavy calculations that shouldn't block the event loop, we can use [Web Workers](https://html.spec.whatwg.org/multipage/workers.html).
+
+That's a way to run code in another, parallel thread.
+
+Web Workers can exchange messages with the main process, but they have their own variables, and their own event loop.
+
+Web Workers do not have access to DOM, so they are useful, mainly, for calculations, to use multiple CPU cores simultaneously.
+```

From f4448781b5f81a7ba7ec38dc5b6e590af7def5ac Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sad=C4=B1k=20=C3=9Cnal=20=C3=87ok=C3=BCnl=C3=BC?=
 <retaler_21@hotmail.com>
Date: Sun, 1 Aug 2021 08:42:31 +0300
Subject: [PATCH 2/5] Add files via upload

---
 2-ui/99-ui-misc/03-event-loop/eventLoop.svg | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 2-ui/99-ui-misc/03-event-loop/eventLoop.svg

diff --git a/2-ui/99-ui-misc/03-event-loop/eventLoop.svg b/2-ui/99-ui-misc/03-event-loop/eventLoop.svg
new file mode 100644
index 000000000..f7de0b6ad
--- /dev/null
+++ b/2-ui/99-ui-misc/03-event-loop/eventLoop.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="479" height="279" viewBox="0 0 479 279"><defs><style>@import url(https://fonts.googleapis.com/css?family=Open+Sans:bold,italic,bolditalic%7CPT+Mono);@font-face{font-family:&apos;PT Mono&apos;;font-weight:700;font-style:normal;src:local(&apos;PT MonoBold&apos;),url(/font/PTMonoBold.woff2) format(&apos;woff2&apos;),url(/font/PTMonoBold.woff) format(&apos;woff&apos;),url(/font/PTMonoBold.ttf) format(&apos;truetype&apos;)}</style></defs><g id="promise" fill="none" fill-rule="evenodd" stroke="none" stroke-width="1"><g id="eventLoop.svg"><path id="Rectangle-1-Copy-5" fill="#FFF9EB" stroke="#E8C48E" stroke-width="2" d="M218 173h108v28H218z"/><text id="..." fill="#8A704D" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="258.9" y="189">...</tspan></text><path id="Rectangle-1-Copy-6" fill="#FFF9EB" stroke="#E8C48E" stroke-width="2" d="M218 90h108v28H218z"/><path id="Rectangle-1-Copy-8" fill="#FFF9EB" stroke="#E8C48E" stroke-width="2" d="M218 117h108v28H218z"/><text id="mousemove" fill="#8A704D" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="233.7" y="136">mousemove</tspan></text><path id="Rectangle-1-Copy-9" fill="#FFF9EB" stroke="#E8C48E" stroke-width="2" d="M218 145h108v28H218z"/><text id="script" fill="#8A704D" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="246.8" y="109">script</tspan></text><text id="event-loop" fill="#000" font-family="OpenSans-Regular, Open Sans" font-size="24" font-weight="normal"><tspan x="69.662" y="134">event</tspan> <tspan x="75.615" y="167">loop</tspan></text><text id="macrotask-queue" fill="#9B9B9B" font-family="OpenSans-Regular, Open Sans" font-size="24" font-weight="normal"><tspan x="345.111" y="136">macrotask</tspan> <tspan x="367.951" y="169">queue</tspan></text><path id="Path" fill="#EE6B47" fill-rule="nonzero" d="M192 40c22.467 0 43.818 7.359 61.285 20.712l.622.479.143.122 8.961 8.422-4.584-14.61 3.817-1.197 6.869 21.895 1.064 3.392-3.452-.852-22.278-5.5.959-3.883 14.864 3.669-8.886-8.352-.55-.424c-16.564-12.656-36.757-19.698-58.036-19.87L192 44c-30.748 0-59.095 14.403-77.315 38.412l-.549.73-3.208-2.387C129.87 55.303 159.664 40 192 40z"/><path id="Path-Copy-2" fill="#EE6B47" fill-rule="nonzero" d="M269.882 208.148l2.823 2.834-.366.365a533.245 533.245 0 00-3.982 4.033l-.333.34c-9.922 10.12-14.79 14.544-22.017 19.272-15.185 9.934-34.01 15.688-51.594 15.688-25.222 0-47.144-6.827-64.077-19.673l-.589-.45-.089-.07-.08-.078-8.854-8.581 4.36 14.68-3.835 1.138-6.532-21.998-1.012-3.409 3.439.906 22.19 5.841-1.018 3.868-14.808-3.898 8.766 8.497.488.374c16.02 12.15 36.782 18.698 60.792 18.85l.859.003c16.796 0 34.862-5.522 49.404-15.035 6.911-4.521 11.624-8.806 21.35-18.725l.334-.34c2.06-2.101 3.135-3.19 4.381-4.432z"/><text id="setTimeout" fill="#8A704D" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="230" y="164">setTimeout</tspan></text></g></g></svg>
\ No newline at end of file

From 6f3e1f2dfd3470c5c0de3519723488fd053fb6fc Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sad=C4=B1k=20=C3=9Cnal=20=C3=87ok=C3=BCnl=C3=BC?=
 <retaler_21@hotmail.com>
Date: Sun, 1 Aug 2021 08:43:02 +0300
Subject: [PATCH 3/5] Add files via upload

---
 2-ui/99-ui-misc/03-event-loop/eventLoop-full.svg | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 2-ui/99-ui-misc/03-event-loop/eventLoop-full.svg

diff --git a/2-ui/99-ui-misc/03-event-loop/eventLoop-full.svg b/2-ui/99-ui-misc/03-event-loop/eventLoop-full.svg
new file mode 100644
index 000000000..201d9a14a
--- /dev/null
+++ b/2-ui/99-ui-misc/03-event-loop/eventLoop-full.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="407" height="391" viewBox="0 0 407 391"><defs><style>@import url(https://fonts.googleapis.com/css?family=Open+Sans:bold,italic,bolditalic%7CPT+Mono);@font-face{font-family:&apos;PT Mono&apos;;font-weight:700;font-style:normal;src:local(&apos;PT MonoBold&apos;),url(/font/PTMonoBold.woff2) format(&apos;woff2&apos;),url(/font/PTMonoBold.woff) format(&apos;woff&apos;),url(/font/PTMonoBold.ttf) format(&apos;truetype&apos;)}</style></defs><g id="promise" fill="none" fill-rule="evenodd" stroke="none" stroke-width="1"><g id="eventLoop-full.svg"><text id="..." fill="#000" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="257.4" y="71">...</tspan></text><path id="Rectangle-1-Copy-6" fill="#FFF9EB" stroke="#E8C48E" stroke-width="2" d="M216 86h108v28H216z"/><path id="Rectangle-1-Copy-8" fill="#FFF9EB" stroke="#E8C48E" stroke-width="2" d="M216 195h108v28H216z"/><text id="mousemove" fill="#8A704D" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="232.2" y="214">mousemove</tspan></text><path id="Rectangle-1-Copy-9" fill="#FFF9EB" stroke="#E8C48E" stroke-width="2" d="M216 302h108v28H216z"/><text id="event-loop" fill="#000" font-family="OpenSans-Regular, Open Sans" font-size="24" font-weight="normal"><tspan x="45.162" y="189">event</tspan> <tspan x="51.115" y="222">loop</tspan></text><text id="render-copy-2" fill="#000" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="297.3" y="176">render</tspan></text><g id="np_paint_2296353_000000-copy-2" fill="#EE6B47" fill-rule="nonzero" transform="translate(256 158)"><path id="Shape" d="M3.079 0A3.095 3.095 0 000 3.079V22.92A3.095 3.095 0 003.079 26H22.92A3.095 3.095 0 0026 22.921V3.08A3.095 3.095 0 0022.921 0H3.08zm0 2.053H22.92c.587 0 1.026.44 1.026 1.026v13.043l-2.886-2.684a1.027 1.027 0 00-1.443.032l-5.72 5.955-5.035-4.148a1.021 1.021 0 00-1.38.075l-5.43 5.43V3.08c0-.587.44-1.026 1.026-1.026zM6.158 3.42A3.095 3.095 0 003.078 6.5a3.095 3.095 0 003.08 3.079A3.095 3.095 0 009.237 6.5a3.095 3.095 0 00-3.08-3.079zm0 2.053c.579 0 1.026.447 1.026 1.026s-.447 1.026-1.026 1.026A1.012 1.012 0 015.132 6.5c0-.579.447-1.026 1.026-1.026zm14.176.566c-.377 0-.759.722-.759 1.08-.46.112-.748.358-.748.716s.371.717.748.717h2.662c.73 0 1.11-1.433-.021-1.433-.022-.677-.445-.86-1.134-.716-.183-.284-.375-.386-.748-.364zM16.71 9.237c-.314 0-.631.584-.631.876-.382.093-.63.296-.63.588 0 .293.316.589.63.589h2.213c.608 0 .931-1.176-.01-1.176-.018-.555-.379-.706-.952-.588-.152-.232-.31-.308-.62-.29zm3.688 6.382l3.55 3.293v4.01c0 .586-.44 1.025-1.027 1.025H3.08a1.01 1.01 0 01-.855-.449l6.05-6.04 4.202 3.453-1.24 1.294 1.475 1.422 7.687-8.008z"/></g><text id="microtasks-copy-2" fill="#000" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="297.5" y="140">microtasks</tspan></text><g id="Group-Copy-2" fill="#EE6B47" transform="translate(256 124)"><path id="Fill-52" d="M23.145.978C21.737.348 20.186 0 18.56 0c-2.59 0-4.983.885-6.921 2.38L10.474.618a.286.286 0 00-.305-.125.303.303 0 00-.226.249L8.797 7.779a.317.317 0 00.07.258.287.287 0 00.22.102h.018l3.112-.206 3.504-.233a.296.296 0 00.258-.204.315.315 0 00-.078-.33l-1.46-1.415a7.18 7.18 0 014.118-1.301c1.07 0 2.083.238 3.003.662a.284.284 0 00.23.003.306.306 0 00.162-.171l1.35-3.568a.314.314 0 00-.159-.398" transform="matrix(-1 0 0 1 32.117 0)"/><path id="Fill-54" d="M12.787 13.315a12.66 12.66 0 001.346 4.7c1.225 2.393 3.101 4.186 5.274 5.27l-.929 1.908a.318.318 0 00.04.342c.077.094.201.13.315.09l6.454-2.269a.3.3 0 00.183-.187.32.32 0 00-.018-.251l-.01-.016-1.644-2.779-1.852-3.127a.29.29 0 00-.295-.142.298.298 0 00-.24.228l-.498 2.018a7.607 7.607 0 01-3.041-3.19 8.083 8.083 0 01-.865-3.087.314.314 0 00-.105-.214.286.286 0 00-.22-.068l-3.636.44a.305.305 0 00-.26.334" transform="matrix(-1 0 0 1 38.273 0)"/><path id="Fill-56" d="M2.646 22.333a12.003 12.003 0 003.205-3.576 12.684 12.684 0 001.713-7.424l2.04-.112a.293.293 0 00.262-.207.316.316 0 00-.084-.332L4.681 5.958a.28.28 0 00-.247-.072.291.291 0 00-.198.14l-.01.018-1.47 2.883-1.654 3.247a.32.32 0 00.03.339.285.285 0 00.307.104l1.916-.558a8.078 8.078 0 01-1.111 4.358 7.652 7.652 0 01-2.117 2.33.31.31 0 00-.123.203.325.325 0 00.053.234l2.183 3.08a.285.285 0 00.406.069" transform="matrix(-1 0 0 1 9.882 0)"/></g><text id="render-copy-2" fill="#000" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="297.3" y="285">render</tspan></text><g id="np_paint_2296353_000000-copy-2" fill="#EE6B47" fill-rule="nonzero" transform="translate(256 267)"><path id="Shape" d="M3.079 0A3.095 3.095 0 000 3.079V22.92A3.095 3.095 0 003.079 26H22.92A3.095 3.095 0 0026 22.921V3.08A3.095 3.095 0 0022.921 0H3.08zm0 2.053H22.92c.587 0 1.026.44 1.026 1.026v13.043l-2.886-2.684a1.027 1.027 0 00-1.443.032l-5.72 5.955-5.035-4.148a1.021 1.021 0 00-1.38.075l-5.43 5.43V3.08c0-.587.44-1.026 1.026-1.026zM6.158 3.42A3.095 3.095 0 003.078 6.5a3.095 3.095 0 003.08 3.079A3.095 3.095 0 009.237 6.5a3.095 3.095 0 00-3.08-3.079zm0 2.053c.579 0 1.026.447 1.026 1.026s-.447 1.026-1.026 1.026A1.012 1.012 0 015.132 6.5c0-.579.447-1.026 1.026-1.026zm14.176.566c-.377 0-.759.722-.759 1.08-.46.112-.748.358-.748.716s.371.717.748.717h2.662c.73 0 1.11-1.433-.021-1.433-.022-.677-.445-.86-1.134-.716-.183-.284-.375-.386-.748-.364zM16.71 9.237c-.314 0-.631.584-.631.876-.382.093-.63.296-.63.588 0 .293.316.589.63.589h2.213c.608 0 .931-1.176-.01-1.176-.018-.555-.379-.706-.952-.588-.152-.232-.31-.308-.62-.29zm3.688 6.382l3.55 3.293v4.01c0 .586-.44 1.025-1.027 1.025H3.08a1.01 1.01 0 01-.855-.449l6.05-6.04 4.202 3.453-1.24 1.294 1.475 1.422 7.687-8.008z"/></g><text id="microtasks-copy-2" fill="#000" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="297.5" y="249">microtasks</tspan></text><g id="Group-Copy-2" fill="#EE6B47" transform="translate(256 233)"><path id="Fill-52" d="M23.145.978C21.737.348 20.186 0 18.56 0c-2.59 0-4.983.885-6.921 2.38L10.474.618a.286.286 0 00-.305-.125.303.303 0 00-.226.249L8.797 7.779a.317.317 0 00.07.258.287.287 0 00.22.102h.018l3.112-.206 3.504-.233a.296.296 0 00.258-.204.315.315 0 00-.078-.33l-1.46-1.415a7.18 7.18 0 014.118-1.301c1.07 0 2.083.238 3.003.662a.284.284 0 00.23.003.306.306 0 00.162-.171l1.35-3.568a.314.314 0 00-.159-.398" transform="matrix(-1 0 0 1 32.117 0)"/><path id="Fill-54" d="M12.787 13.315a12.66 12.66 0 001.346 4.7c1.225 2.393 3.101 4.186 5.274 5.27l-.929 1.908a.318.318 0 00.04.342c.077.094.201.13.315.09l6.454-2.269a.3.3 0 00.183-.187.32.32 0 00-.018-.251l-.01-.016-1.644-2.779-1.852-3.127a.29.29 0 00-.295-.142.298.298 0 00-.24.228l-.498 2.018a7.607 7.607 0 01-3.041-3.19 8.083 8.083 0 01-.865-3.087.314.314 0 00-.105-.214.286.286 0 00-.22-.068l-3.636.44a.305.305 0 00-.26.334" transform="matrix(-1 0 0 1 38.273 0)"/><path id="Fill-56" d="M2.646 22.333a12.003 12.003 0 003.205-3.576 12.684 12.684 0 001.713-7.424l2.04-.112a.293.293 0 00.262-.207.316.316 0 00-.084-.332L4.681 5.958a.28.28 0 00-.247-.072.291.291 0 00-.198.14l-.01.018-1.47 2.883-1.654 3.247a.32.32 0 00.03.339.285.285 0 00.307.104l1.916-.558a8.078 8.078 0 01-1.111 4.358 7.652 7.652 0 01-2.117 2.33.31.31 0 00-.123.203.325.325 0 00.053.234l2.183 3.08a.285.285 0 00.406.069" transform="matrix(-1 0 0 1 9.882 0)"/></g><path id="Path" fill="#EE6B47" fill-rule="nonzero" d="M240.536 23.5c18.067 0 28.19 5.407 30.493 19.865l.067.441.016.179.264 10.223 5.906-11.165 2.652 1.402-8.582 16.229-1.247 2.357-1.367-2.29-9.412-15.76 2.576-1.539 6.476 10.845-.263-10.128-.046-.305c-1.998-12.562-10.586-17.259-27.028-17.353l-.505-.001h-51.072c-18.854 0-27.785 5.925-27.961 22.709l-.003.512v294.675c0 9.183 2.661 14.683 7.881 17.703 4.3 2.487 10.047 3.365 19.488 3.4l.595.001h51.072c9.796 0 15.693-.862 20.083-3.401 5.127-2.966 7.785-8.324 7.878-17.214l.003-.489v-6.472h3v6.472c0 10.183-3.152 16.697-9.379 20.3-4.884 2.825-11.037 3.766-20.972 3.803l-.613.001h-51.072c-10.296 0-16.602-.921-21.585-3.804-6.122-3.542-9.271-9.897-9.376-19.785l-.003-.515V49.721c0-18.944 10.246-26.078 30.352-26.219l.612-.002h51.072z"/><text id="script" fill="#8A704D" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="245.3" y="105">script</tspan></text><text id="setTimeout" fill="#8A704D" font-family="PTMono-Regular, PT Mono" font-size="14" font-weight="normal"><tspan x="228.5" y="321">setTimeout</tspan></text></g></g></svg>
\ No newline at end of file

From d339746e0edd32e0d883504c2c0081825a04b946 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sad=C4=B1k=20=C3=9Cnal=20=C3=87ok=C3=BCnl=C3=BC?=
 <retaler_21@hotmail.com>
Date: Sun, 1 Aug 2021 10:17:59 +0300
Subject: [PATCH 4/5] Update article.md

---
 2-ui/99-ui-misc/03-event-loop/article.md | 145 ++++++++++++-----------
 1 file changed, 73 insertions(+), 72 deletions(-)

diff --git a/2-ui/99-ui-misc/03-event-loop/article.md b/2-ui/99-ui-misc/03-event-loop/article.md
index 3ea0c2c57..77e072233 100644
--- a/2-ui/99-ui-misc/03-event-loop/article.md
+++ b/2-ui/99-ui-misc/03-event-loop/article.md
@@ -1,64 +1,64 @@
 
-# Event loop: microtasks and macrotasks
+# Olay döngüsü: microtasks ve macrotasks
 
-Browser JavaScript execution flow, as well as in Node.js, is based on an *event loop*.
+Node.js'de olduğu gibi tarayıcı JavaScript yürütme akışı da bir *olay döngüsüne* dayanır.
 
-Understanding how event loop works is important for optimizations, and sometimes for the right architecture.
+Olay döngüsünün nasıl çalıştığını anlamak, optimizasyonlar ve bazen de doğru mimari için önemlidir.
 
-In this chapter we first cover theoretical details about how things work, and then see practical applications of that knowledge.
+Bu bölümde önce işlerin nasıl yürüdüğüyle ilgili teorik ayrıntıları ele alacağız ve ardından bu bilginin pratik uygulamalarını göreceğiz.
 
-## Event Loop
+## Olay Döngüsü
 
-The *event loop* concept is very simple. There's an endless loop, where the JavaScript engine waits for tasks, executes them and then sleeps, waiting for more tasks.
+*Olay döngüsü* kavramı çok basittir. JavaScript motorunun görevleri beklediği, yürüttüğü ve daha sonra uyuyarak daha fazla görev beklediği sonsuz bir döngü vardır.
 
-The general algorithm of the engine:
+Motorun genel algoritması:
 
-1. While there are tasks:
-    - execute them, starting with the oldest task.
-2. Sleep until a task appears, then go to 1.
+1. Görevler varken:
+    - en eski görevden başlayarak bunları yürütün.
+2. Bir görev görünene kadar uyuyun, ardından 1'e gidin.
 
-That's a formalization for what we see when browsing a page. The JavaScript engine does nothing most of the time, it only runs if a script/handler/event activates.
+Bu, bir sayfaya göz atarken gördüğümüz şeyin biçimselleştirilmesidir. JavaScript motoru çoğu zaman hiçbir şey yapmaz, yalnızca bir script/işleyici/olay etkinleştirildiğinde çalışır.
 
-Examples of tasks:
+Görev örnekleri:
 
-- When an external script `<script src="...">` loads, the task is to execute it.
-- When a user moves their mouse, the task is to dispatch `mousemove` event and execute handlers.
-- When the time is due for a scheduled `setTimeout`, the task is to run its callback.
-- ...and so on.
+- Harici bir script `<script src="...">` yüklendiğinde, görev onu yürütmektir.
+- Bir kullanıcı faresini hareket ettirdiğinde, görev `mousemove` olayını göndermek ve işleyicileri yürütmektir.
+- Zamanlanmış bir `setTimeout` için zaman geldiğinde, görev callback'i çalıştırmaktır.
+- ...ve benzeri.
 
-Tasks are set -- the engine handles them -- then waits for more tasks (while sleeping and consuming close to zero CPU).
+Görevler belirlenir - motor bunları işler - sonra daha fazla görev bekler (uyurken ve sıfıra yakın CPU tüketirken).
 
-It may happen that a task comes while the engine is busy, then it's enqueued.
+Motor meşgulken bir görev gelebilir, sonra sıraya girebilir.
 
-The tasks form a queue, so-called "macrotask queue" (v8 term):
+Görevler, "macrotask sırası" (v8 terimi) olarak adlandırılan bir sıra oluşturur:
 
 ![](eventLoop.svg)
 
-For instance, while the engine is busy executing a `script`, a user may move their mouse causing `mousemove`, and `setTimeout` may be due and so on, these tasks form a queue, as illustrated on the picture above.
+Örneğin, motor bir `script`'i yürütmekle meşgulken, bir kullanıcı faresini hareket ettirerek `mousemove`'a neden olabilir ve `setTimeout` zamanı gelmiş olabilir ve benzeri, yukarıdaki resimde gösterildiği gibi bu görevler bir kuyruk oluşturur.
 
-Tasks from the queue are processed on "first come – first served" basis. When the engine browser is done with the `script`, it handles `mousemove` event, then `setTimeout` handler, and so on.
+Kuyruktaki görevler "ilk gelene ilk hizmet" esasına göre işlenir. Tarayıcı motoru `script` ile işi bittiğinde, `mousemove` olayını, ardından `setTimeout` işleyicisini vb. işler.
 
-So far, quite simple, right?
+Buraya kadar oldukça basit, değil mi?
 
-Two more details:
-1. Rendering never happens while the engine executes a task. It doesn't matter if the task takes a long time. Changes to the DOM are painted only after the task is complete.
-2. If a task takes too long, the browser can't do other tasks, such as processing user events. So after a time, it raises an alert like "Page Unresponsive", suggesting killing the task with the whole page. That happens when there are a lot of complex calculations or a programming error leading to an infinite loop.
+İki ayrıntı daha:
+1. Motor bir görevi yürütürken oluşturma(Render) asla gerçekleşmez. Görevin uzun sürmesi önemli değil. DOM'daki değişiklikler yalnızca görev tamamlandıktan sonra boyanır.
+2. Bir görev çok uzun sürerse tarayıcı, kullanıcı olaylarını işleme gibi diğer görevleri yapamaz. Bu yüzden bir süre sonra "Sayfa Yanıt Vermiyor" gibi bir uyarı vererek görevi tüm sayfayla sonlandırmayı önerir. Bu, çok sayıda karmaşık hesaplama olduğunda veya sonsuz bir döngüye yol açan bir programlama hatası olduğunda olur.
 
-That was the theory. Now let's see how we can apply that knowledge.
+Teori buydu. Şimdi bu bilgiyi nasıl uygulayabileceğimizi görelim.
 
-## Use-case 1: splitting CPU-hungry tasks
+## Kullanım Senaryosu 1: CPU'ya aç görevleri bölme
 
-Let's say we have a CPU-hungry task.
+Diyelim ki CPU'ya aç bir görevimiz var.
 
-For example, syntax-highlighting (used to colorize code examples on this page) is quite CPU-heavy. To highlight the code, it performs the analysis, creates many colored elements, adds them to the document -- for a large amount of text that takes a lot of time.
+Örneğin, sözdizimi vurgulama(syntax-highlighting) (bu sayfadaki kod örneklerini renklendirmek için kullanılır) oldukça CPU ağırlıklıdır. Kodu vurgulamak için, analizi gerçekleştirir, birçok renkli öğe oluşturur, bunları belgeye ekler - çok fazla zaman alan büyük miktarda metin için.
 
-While the engine is busy with syntax highlighting, it can't do other DOM-related stuff, process user events, etc. It may even cause the browser to "hiccup" or even "hang" for a bit, which is unacceptable.
+Motor sözdizimi vurgulama ile meşgulken, DOM ile ilgili diğer işlemleri yapamaz, kullanıcı olaylarını işleyemez vb. Hatta tarayıcının bir süre "hıçkırmasına" ve hatta "takılmasına" neden olabilir ki bu kabul edilemez bir durumdur.
 
-We can avoid problems by splitting the big task into pieces. Highlight first 100 lines, then schedule `setTimeout` (with zero-delay) for the next 100 lines, and so on.
+Büyük görevi parçalara bölerek sorunlardan kaçınabiliriz. İlk 100 satırı vurgulayın, ardından sonraki 100 satır için "setTimeout" (sıfır gecikmeli) zamanlayın, vb.
 
-To demonstrate this approach, for the sake of simplicity, instead of text-highlighting, let's take a function that counts from `1` to `1000000000`.
+Bu yaklaşımı göstermek için, basitlik adına, metin vurgulama yerine `1` ile `1000000000` arasında sayan bir fonksiyon alalım.
 
-If you run the code below, the engine will "hang" for some time. For server-side JS that's clearly noticeable, and if you are running it in-browser, then try to click other buttons on the page -- you'll see that no other events get handled until the counting finishes.
+Aşağıdaki kodu çalıştırırsanız, motor bir süre "askıda kalır". Açıkça fark edilen sunucu tarafı JS için ve tarayıcıda çalıştırıyorsanız, sayfadaki diğer düğmeleri tıklamayı deneyin - sayım bitene kadar başka hiçbir olayın işlenmediğini göreceksiniz.
 
 ```js run
 let i = 0;
@@ -67,7 +67,7 @@ let start = Date.now();
 
 function count() {
 
-  // do a heavy job
+  // ağır bir iş yap
   for (let j = 0; j < 1e9; j++) {
     i++;
   }
@@ -78,9 +78,9 @@ function count() {
 count();
 ```
 
-The browser may even show a "the script takes too long" warning.
+Tarayıcı, "script çok uzun sürüyor" uyarısı bile gösterebilir.
 
-Let's split the job using nested `setTimeout` calls:
+İşi iç içe `setTimeout` çağrılarını kullanarak bölelim:
 
 ```js run
 let i = 0;
@@ -89,7 +89,7 @@ let start = Date.now();
 
 function count() {
 
-  // do a piece of the heavy job (*)
+  // ağır işin bir parçasını yap (*)
   do {
     i++;
   } while (i % 1e6 != 0);
@@ -97,7 +97,7 @@ function count() {
   if (i == 1e9) {
     alert("Done in " + (Date.now() - start) + 'ms');
   } else {
-    setTimeout(count); // schedule the new call (**)
+    setTimeout(count); // yeni cağrıyı planla (**)
   }
 
 }
@@ -105,21 +105,22 @@ function count() {
 count();
 ```
 
-Now the browser interface is fully functional during the "counting" process.
+Artık tarayıcı arayüzü "sayma" işlemi sırasında tamamen işlevseldir.
 
 A single run of `count` does a part of the job `(*)`, and then re-schedules itself `(**)` if needed:
+Tek bir `count` çalıştırması `(*)` işinin bir bölümünü yapar ve ardından gerekirse kendisini `(**)` olarak yeniden zamanlar:
 
-1. First run counts: `i=1...1000000`.
-2. Second run counts: `i=1000001..2000000`.
-3. ...and so on.
+1. İlk çalıştırma sayar: `i=1...1000000`.
+2. İkinci çalıştırma sayar: `i=1000001..2000000`.
+3. ...ve benzeri.
 
-Now, if a new side task (e.g. `onclick` event) appears while the engine is busy executing part 1, it gets queued and then executes when part 1 finished, before the next part. Periodic returns to the event loop between `count` executions provide just enough "air" for the JavaScript engine to do something else, to react to other user actions.
+Şimdi, motor bölüm 1'i yürütmekle meşgulken yeni bir yan görev (örneğin `onclick` olayı) ortaya çıkarsa, sıraya alınır ve sonraki bölümden önce bölüm 1 bittiğinde yürütülür. `count` yürütmeleri arasındaki olay döngüsüne periyodik geri dönüşler, JavaScript motorunun başka bir şey yapması, diğer kullanıcı eylemlerine tepki vermesi için yeterli "hava" sağlar.
 
-The notable thing is that both variants -- with and without splitting the job by `setTimeout` -- are comparable in speed. There's not much difference in the overall counting time.
+Dikkate değer olan şey, her iki varyantın da -- işi `setTimeout` ile bölerek ve bölmeden -- hız açısından karşılaştırılabilir olmasıdır. Toplam sayım süresinde pek bir fark yok.
 
-To make them closer, let's make an improvement.
+Onları daha da yakınlaştırmak için bir iyileştirme yapalım.
 
-We'll move the scheduling to the beginning of the `count()`:
+Zamanlamayı `count()`un başına taşıyacağız:
 
 ```js run
 let i = 0;
@@ -128,9 +129,9 @@ let start = Date.now();
 
 function count() {
 
-  // move the scheduling to the beginning
+  // zamanlamayı en başa taşı
   if (i < 1e9 - 1e6) {
-    setTimeout(count); // schedule the new call
+    setTimeout(count); // yeni cağrıyı planla 
   }
 
   do {
@@ -146,25 +147,25 @@ function count() {
 count();
 ```
 
-Now when we start to `count()` and see that we'll need to `count()` more, we schedule that immediately, before doing the job.
+Şimdi `count()` yapmaya başladığımızda ve daha fazla `count()` yapmamız gerektiğini gördüğümüzde, işi yapmadan önce bunu hemen zamanlıyoruz.
 
-If you run it, it's easy to notice that it takes significantly less time.
+Çalıştırırsanız, önemli ölçüde daha az zaman aldığını fark etmek kolaydır.
 
-Why?  
+Neden?  
 
-That's simple: as you remember, there's the in-browser minimal delay of 4ms for many nested `setTimeout` calls. Even if we set `0`, it's `4ms` (or a bit more). So the earlier we schedule it - the faster it runs.
+Çok basit: Hatırladığınız gibi, iç içe geçmiş birçok `setTimeout` çağrısı için tarayıcıda minimum 4 ms gecikme vardır. `0` ayarlasak bile, `4ms` (veya biraz daha fazla). Yani ne kadar erken zamanlarsak o kadar hızlı çalışır.
 
-Finally, we've split a CPU-hungry task into parts - now it doesn't block the user interface. And its overall execution time isn't much longer.
+Son olarak, CPU'ya aç bir görevi parçalara ayırdık - artık kullanıcı arayüzünü engellemiyor. Ve genel yürütme süresi çok daha uzun değil.
 
-## Use case 2: progress indication
+## Kullanım Senaryosu 2: ilerleme göstergesi
 
-Another benefit of splitting heavy tasks for browser scripts is that we can show progress indication.
+Tarayıcı komut dosyaları için ağır görevleri bölmenin bir başka yararı da ilerleme göstergesi gösterebilmemizdir.
 
-As mentioned earlier, changes to DOM are painted only after the currently running task is completed, irrespective of how long it takes.
+Daha önce belirtildiği gibi, DOM'daki değişiklikler, ne kadar sürdüğüne bakılmaksızın, yalnızca şu anda çalışan görev tamamlandıktan sonra boyanır.
 
-On one hand, that's great, because our function may create many elements, add them one-by-one to the document and change their styles -- the visitor won't see any "intermediate", unfinished state. An important thing, right?
+Bir yandan, bu harika, çünkü fonksiyonumuz birçok öğe oluşturabilir, bunları tek tek belgeye ekleyebilir ve stillerini değiştirebilir -- ziyaretçi herhangi bir "ara", tamamlanmamış durum görmez. Önemli bir şey, değil mi?
 
-Here's the demo, the changes to `i` won't show up until the function finishes, so we'll see only the last value:
+İşte demo, `i`'deki değişiklikler fonksiyon bitene kadar görünmeyecek, bu yüzden yalnızca son değeri göreceğiz:
 
 
 ```html run
@@ -183,11 +184,11 @@ Here's the demo, the changes to `i` won't show up until the function finishes, s
 </script>
 ```
 
-...But we also may want to show something during the task, e.g. a progress bar.
+...Ancak görev sırasında da bir şey göstermek isteyebiliriz, örneğin bir ilerleme çubuğu.
 
-If we split the heavy task into pieces using `setTimeout`, then changes are painted out in-between them.
+Eğer ağır görevi `setTimeout` kullanarak parçalara ayırırsak, o zaman değişiklikler aralarında boyanır.
 
-This looks prettier:
+Bu daha güzel görünüyor:
 
 ```html run
 <div id="progress"></div>
@@ -197,7 +198,7 @@ This looks prettier:
 
   function count() {
 
-    // do a piece of the heavy job (*)
+    // ağır işin bir parçasını yap (*)
     do {
       i++;
       progress.innerHTML = i;
@@ -213,14 +214,14 @@ This looks prettier:
 </script>
 ```
 
-Now the `<div>` shows increasing values of `i`, a kind of a progress bar.
+Şimdi `<div>`, bir tür ilerleme çubuğu olan `i`'nin artan değerlerini gösteriyor.
 
 
-## Use case 3: doing something after the event
+## Kullanım Senaryosu 3: olaydan sonra bir şeyler yapmak
 
-In an event handler we may decide to postpone some actions until the event bubbled up and was handled on all levels. We can do that by wrapping the code in zero delay `setTimeout`.
+Bir olay işleyicide, bazı eylemleri olay kabarıp tüm seviyelerde işlenene kadar ertelemeye karar verebiliriz. Bunu, kodu sıfır gecikmeli `setTimeout` içine sararak yapabiliriz.
 
-In the chapter <info:dispatch-events> we saw an example: custom event `menu-open` is dispatched in `setTimeout`, so that it happens after the "click" event is fully handled.
+<info:dispatch-events> bölümünde bir örnek gördük: `menu-open` özel olayı(custom event) `setTimeout` içinde gönderilir, böylece click" olayı tamamen işlendikten sonra gerçekleşir.
 
 ```js
 menu.onclick = function() {
@@ -236,17 +237,17 @@ menu.onclick = function() {
 };
 ```
 
-## Macrotasks and Microtasks
+## Macrotasks ve Microtasks
 
-Along with *macrotasks*, described in this chapter, there are *microtasks*, mentioned in the chapter <info:microtask-queue>.
+Bu bölümde açıklanan *macrotasks* ile birlikte, <info:microtasks-sırası> bölümünde bahsedilen *microtasks* vardır.
 
-Microtasks come solely from our code. They are usually created by promises: an execution of `.then/catch/finally` handler becomes a microtask. Microtasks are used "under the cover" of `await` as well, as it's another form of promise handling.
+Microtask'ler yalnızca kodumuzdan gelir. Genellikle promise'larla oluşturulurlar: `.then/catch/finally` işleyicisinin yürütülmesi bir microtask haline gelir. Microtask'ler, bir başka promise işleme biçimi olduğu için, `wait`'in "örtüsü altında" da kullanılır.
 
-There's also a special function `queueMicrotask(func)` that queues `func` for execution in the microtask queue.
+Ayrıca, microtask kuyruğunda yürütülmek üzere `func`'u sıraya sokan özel bir `queueMicrotask(func)` fonksiyonu da vardır.
 
-**Immediately after every *macrotask*, the engine executes all tasks from *microtask* queue, prior to running any other macrotasks or rendering or anything else.**
+**Her macrotask'dan hemen sonra, motor, diğer macrotask'ları çalıştırmadan veya oluşturmadan veya başka herhangi bir şeyden önce tüm görevleri microtask kuyruğundan yürütür.**
 
-For instance, take a look:
+Örneğin, bir göz atın:
 
 ```js run
 setTimeout(() => alert("timeout"));

From 841b9219141d7bfe099501dccb86807c6b0ee3e1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sad=C4=B1k=20=C3=9Cnal=20=C3=87ok=C3=BCnl=C3=BC?=
 <retaler_21@hotmail.com>
Date: Sun, 1 Aug 2021 21:04:31 +0300
Subject: [PATCH 5/5] Update article.md

---
 2-ui/99-ui-misc/03-event-loop/article.md | 71 ++++++++++++------------
 1 file changed, 36 insertions(+), 35 deletions(-)

diff --git a/2-ui/99-ui-misc/03-event-loop/article.md b/2-ui/99-ui-misc/03-event-loop/article.md
index 77e072233..26a80afe9 100644
--- a/2-ui/99-ui-misc/03-event-loop/article.md
+++ b/2-ui/99-ui-misc/03-event-loop/article.md
@@ -221,25 +221,25 @@ Bu daha güzel görünüyor:
 
 Bir olay işleyicide, bazı eylemleri olay kabarıp tüm seviyelerde işlenene kadar ertelemeye karar verebiliriz. Bunu, kodu sıfır gecikmeli `setTimeout` içine sararak yapabiliriz.
 
-<info:dispatch-events> bölümünde bir örnek gördük: `menu-open` özel olayı(custom event) `setTimeout` içinde gönderilir, böylece click" olayı tamamen işlendikten sonra gerçekleşir.
+<bilgi:olayları gönderme(dispatch-events)> bölümünde bir örnek gördük: `menu-open` özel olayı(custom event) `setTimeout` içinde gönderilir, böylece "click" olayı tamamen işlendikten sonra gerçekleşir.
 
 ```js
 menu.onclick = function() {
   // ...
 
-  // create a custom event with the clicked menu item data
+  // tıklanan menü öğesi verileriyle özel bir olay oluşturun
   let customEvent = new CustomEvent("menu-open", {
     bubbles: true
   });
 
-  // dispatch the custom event asynchronously
+  // özel olayı eşzamansız(asynchronously) olarak gönder
   setTimeout(() => menu.dispatchEvent(customEvent));
 };
 ```
 
 ## Macrotasks ve Microtasks
 
-Bu bölümde açıklanan *macrotasks* ile birlikte, <info:microtasks-sırası> bölümünde bahsedilen *microtasks* vardır.
+Bu bölümde açıklanan *macrotask*'ler ile birlikte, <bilgi:microtasks-sırası> bölümünde bahsedilen *microtask*'ler vardır.
 
 Microtask'ler yalnızca kodumuzdan gelir. Genellikle promise'larla oluşturulurlar: `.then/catch/finally` işleyicisinin yürütülmesi bir microtask haline gelir. Microtask'ler, bir başka promise işleme biçimi olduğu için, `wait`'in "örtüsü altında" da kullanılır.
 
@@ -258,23 +258,24 @@ Promise.resolve()
 alert("code");
 ```
 
-What's going to be the order here?
+Buradaki sıra ne olacak?
 
-1. `code` shows first, because it's a regular synchronous call.
-2. `promise` shows second, because `.then` passes through the microtask queue, and runs after the current code.
-3. `timeout` shows last, because it's a macrotask.
+1. Sıradan bir eşzamanlı(synchronous) çağrı olduğu için önce `kod` gösterilir.
+2. `promise` ikinci sıradadır, çünkü `.then` microtask kuyruğundan geçer ve geçerli koddan sonra çalışır.
+3. `timeout`'u en son gösterir, çünkü bu bir macrotask'dir.
 
-The richer event loop picture looks like this (order is from top to bottom, that is: the script first, then microtasks, rendering and so on):
+Daha zengin olay döngüsü resmi şöyle görünür (sıra yukarıdan aşağıya doğrudur, yani: önce script, ardından microtask'ler, oluşturma(rendering) vb.):
 
 ![](eventLoop-full.svg)
 
-All microtasks are completed before any other event handling or rendering or any other macrotask takes place.
+Tüm microtask'ler, başka herhangi bir olay işleme(handling) veya oluşturma(rendering) veya başka herhangi bir macrotask gerçekleşmeden önce tamamlanır.
 
-That's important, as it guarantees that the application environment is basically the same (no mouse coordinate changes, no new network data, etc) between microtasks.
+Uygulama ortamının microtask'ler arasında temelde aynı olmasını (fare koordinat değişikliği yok, yeni ağ verisi yok, vb.) garanti ettiği için bu önemlidir.
 
-If we'd like to execute a function asynchronously (after the current code), but before changes are rendered or new events handled, we can schedule it with `queueMicrotask`.
+Bir fonksiyonu eşzamansız(asynchronously) olarak (geçerli koddan sonra) yürütmek istiyorsak, ancak değişiklikler oluşturulmadan(rendered) veya yeni olaylar işlenmeden(handled) önce, bunu `queueMicrotask` ile zamanlayabiliriz.
 
 Here's an example with "counting progress bar", similar to the one shown previously, but `queueMicrotask` is used instead of `setTimeout`. You can see that it renders at the very end. Just like the synchronous code:
+Burada, daha önce gösterilene benzer bir "sayan ilerleme çubuğu" örneği verilmiştir, ancak `setTimeout` yerine `queueMicrotask` kullanılmıştır. En sonunda oluştuğunu(render) görebilirsiniz. Tıpkı senkron kod gibi:
 
 ```html run
 <div id="progress"></div>
@@ -284,7 +285,7 @@ Here's an example with "counting progress bar", similar to the one shown previou
 
   function count() {
 
-    // do a piece of the heavy job (*)
+    // ağır işin bir parçasını yap (*)
     do {
       i++;
       progress.innerHTML = i;
@@ -302,39 +303,39 @@ Here's an example with "counting progress bar", similar to the one shown previou
 </script>
 ```
 
-## Summary
+## Özet
 
-A more detailed event loop algorithm (though still simplified compared to the [specification](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model)):
+Daha ayrıntılı bir olay döngüsü algoritması (yine de [spesifikasyona](https://html.spec.whatwg.org/multipage/webappapis.html#event-loop-processing-model) kıyasla basitleştirilmiş olsa da):
 
-1. Dequeue and run the oldest task from the *macrotask* queue (e.g. "script").
-2. Execute all *microtasks*:
-    - While the microtask queue is not empty:
-        - Dequeue and run the oldest microtask.
-3. Render changes if any.
-4. If the macrotask queue is empty, wait till a macrotask appears.
-5. Go to step 1.
+1. En eski görevi *macrotask* kuyruğundan ayırın ve çalıştırın (ör. "script").
+2. Tüm *microtask*'leri yürütün:
+    - Microtask kuyruğu boş değilken:
+        - En eski microtask'i sıraya alın ve çalıştırın.
+3. Varsa oluşturme(render) değişiklikleri.
+4. Macrotask kuyruğu boşsa, bir macrotask görünene kadar bekleyin.
+5. 1.Adıma gidin.
 
-To schedule a new *macrotask*:
-- Use zero delayed `setTimeout(f)`.
+Yeni bir *macrotask* zamanlamak için:
+- Sıfır gecikmeli `setTimeout(f)` kullanın.
 
-That may be used to split a big calculation-heavy task into pieces, for the browser to be able to react to user events and show progress between them.
+Bu, tarayıcının kullanıcı olaylarına tepki verebilmesi ve aralarındaki ilerlemeyi gösterebilmesi için büyük bir hesaplama ağırlıklı görevi parçalara ayırmak için kullanılabilir.
 
-Also, used in event handlers to schedule an action after the event is fully handled (bubbling done).
+Ayrıca, olay tamamen işlendikten (köpürme işlemi) sonra bir eylem zamanlamak için olay işleyicilerinde kullanılır.
 
-To schedule a new *microtask*
-- Use `queueMicrotask(f)`.
-- Also promise handlers go through the microtask queue.
+Yeni bir *microtask* planlamak için
+- `queueMicrotask(f)` kullanın.
+- Ayrıca promise işleyicileri microtask kuyruğundan geçer.
 
-There's no UI or network event handling between microtasks: they run immediately one after another.
+Microtask'ler arasında UI veya ağ olayı işleme yoktur: Bunlar birbiri ardına hemen çalışır.
 
-So one may want to `queueMicrotask` to execute a function asynchronously, but within the environment state.
+Bu nedenle, bir fonksiyonu eşzamansız(asynchronously) olarak ancak ortam durumu içinde yürütmek için `queueMicrotask` isteyebilirsiniz.
 
 ```smart header="Web Workers"
-For long heavy calculations that shouldn't block the event loop, we can use [Web Workers](https://html.spec.whatwg.org/multipage/workers.html).
+Olay döngüsünü engellememesi gereken uzun ağır hesaplamalar için [Web Workers](https://html.spec.whatwg.org/multipage/workers.html)'ı kullanabiliriz.
 
-That's a way to run code in another, parallel thread.
+Bu, başka bir paralel iş parçacığında(thread) kod çalıştırmanın bir yoludur.
 
-Web Workers can exchange messages with the main process, but they have their own variables, and their own event loop.
+Web Workers ana süreçle mesaj alışverişinde bulunabilirler, ancak kendi değişkenleri ve kendi olay döngüleri vardır.
 
-Web Workers do not have access to DOM, so they are useful, mainly, for calculations, to use multiple CPU cores simultaneously.
+Web Worker'larının DOM'a erişimi yoktur, bu nedenle, esas olarak hesaplamalar için, aynı anda birden fazla CPU çekirdeği kullanmak için yararlıdırlar.
 ```