Merge pull request #388 from brentguf/callbacks

Callbacks chapter

6-async/01-callbacks/article.md

@@ -2,7 +2,7 @@
 
 # Introduction: callbacks
 
-Many actions in Javascript are *asynchronous*.
+Many actions in JavaScript are *asynchronous*.
 
 For instance, take a look at the function `loadScript(src)`:
 
@@ -23,7 +23,7 @@ We can use it like this:
 loadScript('/my/script.js');
 ```
 
-The function is called "asynchronous", because the action (script loading) finishes not now, but later.
+The function is called "asynchronously", because the action (script loading) finishes not now, but later.
 
 The call initiates the script loading, then the execution continues. While the script is loading, the code below may finish executing, and if the loading takes time, other scripts may run meanwhile too.
 
@@ -35,7 +35,7 @@ loadScript('/my/script.js');
 
 Now let's say we want to use the new script when it loads. It probably declares new functions, so we'd like to run them.
 
-...But if we do that immediately after the `loadScript(…)` call, that wouldn't work:
+But if we do that immediately after the `loadScript(…)` call, that wouldn't work:
 
 ```js
 loadScript('/my/script.js'); // the script has "function newFunction() {…}"
@@ -45,7 +45,7 @@ newFunction(); // no such function!
 */!*
 ```
 
-Naturally, the browser probably didn't have time to load the script. So the immediate call to the new function fails. As of now, `loadScript` function 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 new functions and variables from that script.
+Naturally, the browser probably didn't have time to load the script. So the immediate call to the new function fails. As of now, `loadScript` function 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 it happens, to use new functions and variables from that script.
 
 Let's add a `callback` function as a second argument to `loadScript` that should execute when the script loads:
 
@@ -118,7 +118,7 @@ loadScript('/my/script.js', function(script) {
 
 After the outer `loadScript` is complete, the callback initiates the inner one.
 
-...What if we want one more script?
+What if we want one more script...?
 
 ```js
 loadScript('/my/script.js', function(script) {
@@ -183,7 +183,7 @@ So the single `callback` function is used both for reporting errors and passing
 
 From the first look it's a viable way of asynchronous coding. And indeed it is. For one or maybe two nested calls it looks fine.
 
-But for multiple asynchronous actions that follow one after another we'll have a code like this:
+But for multiple asynchronous actions that follow one after another we'll have code like this:
 
 ```js
 loadScript('1.js', function(error, script) {
@@ -264,8 +264,8 @@ See? It does the same, and there's no deep nesting now, because we made every ac
 
 It works, but the code looks like a torn apart spreadsheet. It's difficult to read, you probably noticed that. One needs to eye-jump between pieces while reading it. That's inconvenient, especially the reader is not familiar with the code and doesn't know where to eye-jump.
 
-Also the functions named `step*` are all of a single use, they are created only to evade the "pyramid of doom". No one is going to reuse them outside of the action chain. So there's a bit of a namespace cluttering here.
+Also the functions named `step*` are all of a single use, they are created only to avoid the "pyramid of doom". No one is going to reuse them outside of the action chain. So there's a bit of a namespace cluttering here.
 
 We'd like to have a something better.
 
-Luckily, there are other ways to evade such pyramids. One of the best ways is to use "promises", described in the next chapter.
+Luckily, there are other ways to avoid such pyramids. One of the best ways is to use "promises", described in the next chapter.