From 3b681c8ceb616b887733d7d3ff5704cd1bfd062d Mon Sep 17 00:00:00 2001
From: Peter Roche <46547072+paroche@users.noreply.github.com>
Date: Tue, 11 Feb 2020 22:32:10 -0700
Subject: [PATCH] Update article.md

"returns to event loop" -> "returns to the event loop"
"no much difference" -> "not much difference"
---
 2-ui/99-ui-misc/03-event-loop/article.md | 4 ++--
 1 file changed, 2 insertions(+), 2 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 218dd214..18971e59 100644
--- a/2-ui/99-ui-misc/03-event-loop/article.md
+++ b/2-ui/99-ui-misc/03-event-loop/article.md
@@ -113,9 +113,9 @@ A single run of `count` does a part of the job `(*)`, and then re-schedules itse
 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 event loop between `count` executions provide just enough "air" for the JavaScript engine to do something else, to react on other user actions.
+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 on other user actions.
 
-The notable thing is that both variants -- with and without splitting the job by `setTimeout` -- are comparable in speed. There's no much difference in the overall counting time.
+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.