javascript-tutorial
diff --git a/‎1-js/07-object-oriented-programming/03-prototype-inheritance/article.md
Lines changed: 1 addition & 1 deletion b/‎1-js/07-object-oriented-programming/03-prototype-inheritance/article.md
Lines changed: 1 addition & 1 deletion
diff --git a/‎2-ui/1-document/06-dom-attributes-and-properties/article.md
Lines changed: 1 addition & 1 deletion b/‎2-ui/1-document/06-dom-attributes-and-properties/article.md
Lines changed: 1 addition & 1 deletion
diff --git a/‎2-ui/3-event-details/10-onload-ondomcontentloaded/article.md
Lines changed: 1 addition & 1 deletion b/‎2-ui/3-event-details/10-onload-ondomcontentloaded/article.md
Lines changed: 1 addition & 1 deletion
diff --git a/‎5-animation/3-js-animation/article.md
Lines changed: 6 additions & 6 deletions b/‎5-animation/3-js-animation/article.md
Lines changed: 6 additions & 6 deletions
diff --git a/‎5-animation/3-js-animation/text.view/index.html
Lines changed: 1 addition & 1 deletion b/‎5-animation/3-js-animation/text.view/index.html
Lines changed: 1 addition & 1 deletion
diff --git a/‎8-async/01-callback-hell/article.md
Lines changed: 22 additions & 11 deletions b/‎8-async/01-callback-hell/article.md
Lines changed: 22 additions & 11 deletions
@@ -174,7 +174,7 @@ let user = {
 
   set fullName(value) {
     [this.name, this.surname] = value.split(" ");
-  }
+  },
 
   get fullName() {
     return `${this.name} ${this.surname}`;
 
@@ -139,7 +139,7 @@ Please note:
 
 1. `getAttribute('About')` -- the first letter is uppercase here, and in HTML it's all lowercase. But that doesn't matter: attribute names are case-insensitive.
 2. We can assign anything to an attribute, but that becomes a string. So here we have `"123"` as the value.
-3. All attributes including ones that we set are seen in `innerHTML`.
+3. All attributes including ones that we set are visible in `outerHTML`.
 4. The `attributes` collection is iterable and has all attributes with `name` and `value`.
 
 ## Property-attribute synchronization
 
@@ -67,7 +67,7 @@ There are two differences between them.
 |         | `async` | `defer` |
 |---------|---------|---------|
 | Order | Scripts with `async` execute *in the load-first order*. Their document order doesn't matter -- which loads first runs first. | Scripts with `defer` always execute *in the document order* (as they go in the document). |
-| `DOMContentLoaded` | Scripts with `async` may load and execute while the document has not yet been fully downloaded. | Scripts with `defer` execute after the document is loaded and parsed (they wait if needed), right before `DOMContentLoaded`. |
+| `DOMContentLoaded` | Scripts with `async` may load and execute while the document has not yet been fully downloaded. That happens if scripts are small or cached, and the document is long enough. | Scripts with `defer` execute after the document is loaded and parsed (they wait if needed), right before `DOMContentLoaded`. |
 
 So `async` is used for totally independent scripts.
 
 
@@ -186,7 +186,7 @@ Function `animate` accepts 3 parameters that essentially describes the animation
 
 Let's animate the element `width` from `0` to `100%` using our function.
 
-Click for the demo:
+Click on the element for the demo:
 
 [codetabs height=60 src="width"]
 
@@ -410,19 +410,19 @@ As we can see, the graph of the first half of the animation is the scaled down `
 
 ## More interesting "draw"
 
-Instead of moving the element we can do something else. All we need is to write the write `draw`
-
-### Typing in the text
+Instead of moving the element we can do something else. All we need is to write the write the proper `draw`.
 
 Here's the animated "bouncing" text typing:
 
 [codetabs src="text"]
 
 ## Summary
 
-JavaScript animation is implemented with the help of `requestAnimationFrame`.
+JavaScript animation should be implemented via `requestAnimationFrame`. That built-in method allows to setup a callback function to run when the browser will be preparing a repaint. Usually that's very soon, but the exact time depends on the browser.
+
+When a page is in the background, there are no repaints at all, so the callback won't run: the animation will be suspended and won't consume resources. That's great.
 
-The helper `animate` function:
+Here's the helper `animate` function to setup most animations:
 
 ```js
 function animate({timing, draw, duration}) {
 
@@ -10,7 +10,7 @@
 <body>
 
 
-  <textarea id="textExample" rows="4" cols="60">He took his vorpal sword in hand:
+  <textarea id="textExample" rows="5" cols="60">He took his vorpal sword in hand:
 Long time the manxome foe he sought—
 So rested he by the Tumtum tree,
 And stood awhile in thought.
 
@@ -30,32 +30,35 @@ A *synchronous* action suspends the execution until it's completed. For instance
 ```js
 let age = prompt("How old are you", 20);
 // the execution of the code below awaits for the prompt to finish
+// the script hangs
 ```
 
 An *asynchronous* action allows the program to continue while it's in progress. For instance, a call to `loadScript` is asynchronous. It initiates the script loading, but does not suspend the execution. Other commands may execute while the script is loading:
 
 ```js
 loadScript('/my/script.js');
-// the execution does not wait for the script loading to finish,
-// it just goes on
+// the execution of the code below *does not* wait for the script loading to finish,
+// it just continues
 ```
 
-As of now, `loadScript` provides no way to track the load completion. The script loads and eventually runs.
+As of now, the `loadScript` function loads the script, doesn't provide a way to track the load completion. The script loads and eventually runs, that's all. But we'd like to know when happens, to use additional functions and variables from that script.
 
-Let's add a `callback` function as a second argument to `loadScript`, that should execute at when the script is loaded.
+Let's add a `callback` function as a second argument to `loadScript` that should execute when the script loads:
 
 ```js
 function loadScript(src, callback) {
   let script = document.createElement('script');
   script.src = src;
 
+*!*
   script.onload = () => callback(script);
+*/!*
 
   document.head.append(script);
 }
 ```
 
-Now we're able to load a script and run our code that can use new functions from it, like here:
+Now we're able to load a script and then run our code that can use new functions from it, like here:
 
 ```js run
 function loadScript(src, callback) {
@@ -73,7 +76,9 @@ loadScript('https://cdnjs.cloudflare.com/ajax/libs/lodash.js/3.2.0/lodash.js', f
 */!*
 ```
 
-That's called a "callback style" of asynchronous programming. A function that does something asynchronously provides a callback argument where we put the code to run after it's complete.
+That's called a "callback-based" style of asynchronous programming. A function that does something asynchronously should provide a `callback` argument where we put the function to run after it's complete.
+
+Here it was used for `loadScript`, but of course it's a general approach.
 
 ## Callback in callback
 
@@ -151,10 +156,10 @@ loadScript('/my/script.js', function(error, script) {
 ```
 
 The convention is:
-1. The first argument of `callback` is reserved for an error if it occurs.
-2. The second argument (and successive ones if needed) are for the successful result.
+1. The first argument of `callback` is reserved for an error if it occurs. Then `callback(err)` is called.
+2. The second argument and successive ones if needed are for the successful result. Then `callback(null, result1, result2…)` is called.
 
-So the single `callback` function is used both for reporting errors and passing back results.
+So the single `callback` function is used both for reporting errors and passing back results. That's called "error-first callback" style. Or we could use different functions for successful and erroneous completion.
 
 ## Pyramid of doom
 
@@ -203,6 +208,8 @@ That's sometimes called "callback hell" or "pyramid of doom".
 
 The pyramid grows to the right with every asynchronous action. Soon it spirales out of control.
 
+So this way of coding appears not so good.
+
 In simple cases we can evade the problem by making every action a standalone function, like this:
 
 ```js
@@ -235,6 +242,10 @@ function step3(error, script) {
 };
 ```
 
-See? There's no deep nesting now, because we moved every function to the top. But the code looks like a torn apart spreadsheet. We need to eye-jump between pieces while reading it. The functions `step*` have no use, they are only created to evade the "pyramid of doom".
+See? It does the same, and there's no deep nesting now, because we moved every function to the top. But the code looks like a torn apart spreadsheet. We need to eye-jump between pieces while reading it. It's not very readable, especially if you are not familiar with it and don't know where to eye-jump.
+
+Also the functions `step*` have no use, they are only created to evade the "pyramid of doom".
+
+So we'd like to have a better way of coding for complex asynchronous actions.
 
-Luckily, there are other ways to evade such pyramids. Most modern code makes use of "promises", we'll study them in the next chapter.
+Luckily, there are other ways to evade such pyramids. For instance, we can use "promises", described in the next chapter.