diff --git a/chapters/ch01.asciidoc b/chapters/ch01.asciidoc
index 5472201..b675847 100644
--- a/chapters/ch01.asciidoc
+++ b/chapters/ch01.asciidoc
@@ -45,7 +45,7 @@ The sixth edition is a significant milestone in the history of JavaScript. Besid
 
 Having spent ten years without observing significant change to the language specification after ES3, and four years for ES6 to materialize, it was clear the TC39 process needed to improve. The revision process used to be deadline-driven. Any delay in arriving at consensus would cause long wait periods between revisions, which lead to feature creep, causing more delays. Minor revisions were delayed by large additions to the specification, and large additions faced pressure to finalize so that the revision would be pushed through avoiding further delays.
 
-Since ES6 came out, TC39 has streamlinedfootnote:[You can find the September 2013 presentation which lead to the streamlined proposal revisioning process here: https://mjavascript.com/out/tc39-improvement.] its proposal revisioning process and adjusted it to meet modern expectations: the need to iterate more often and consistently, and to democratize specification development. At this point, TC39 moved from an ancient Word-based flow to using ecmarkup and GitHub Pull Requests, greatly increasing the number of proposalsfootnoteref:[proposals,You can find all proposals being considered by TC39 at https://mjavascript.com/out/tc39-proposals.] being created as well as external participation by non-members.
+Since ES6 came out, TC39 has streamlinedfootnote:[You can find the September 2013 presentation which lead to the streamlined proposal revisioning process here: https://mjavascript.com/out/tc39-improvement.] its proposal revisioning process and adjusted it to meet modern expectations: the need to iterate more often and consistently, and to democratize specification development. At this point, TC39 moved from an ancient Word-based flow to using ecmarkup (an HTML superset used to format ECMAScript specifications) and GitHub Pull Requests, greatly increasing the number of proposalsfootnoteref:[proposals,You can find all proposals being considered by TC39 at https://mjavascript.com/out/tc39-proposals.] being created as well as external participation by non-members.
 
 Firefox, Chrome, Edge, Safari and Node.js all offer over 95% compliance of the ES6 specification,footnote:[For a detailed ES6 compatibility report across browsers, check out the following table: https://mjavascript.com/out/es6-compat.] but we’ve been able to use the features as they came out in each of these browsers rather than having to wait until the flip of a switch when their implementation of ES6 was 100% finalized.
 
@@ -73,7 +73,7 @@ Babel and similar compilers that take code as input and produce output native to
 
 This transformation can be done at build-time, so that consumers receive code that's well supported by their JavaScript runtime of choice. This mechanism improves the runtime support baseline, giving JavaScript developers the ability to take advantage of new language features and syntax sooner. It is also significantly beneficial to specification writers and implementors, as it allows them to collect feedback regarding viability, desirability, and possible bugs or corner cases.
 
-A transpiler can take the ES6 source code we write and produce ES5 code that browsers can interpret more consistently. This is the most reliable way of running ES6 code in production today: using a build step to produce ES5 code that any modern browser can execute.
+A transpiler can take the ES6 source code we write and produce ES5 code that browsers can interpret more consistently. This is the most reliable way of running ES6 code in production today: using a build step to produce ES5 code that most old browsers, as well as modern browsers, can execute.
 
 The same applies to ES7 and beyond. As new versions of the language specification are released every year, we can expect compilers to support ES2017 input, ES2018 input and beyond. Similarly, as browser support becomes better, we can also expect compilers to reduce complexity in favor of ES6 output, then ES7 output, and so on. In this sense, we can think of JavaScript-to-JavaScript transpilers as a moving window that takes code written using the latest available language semantics and produces the most modern code they can output without compromising browser support.
 
@@ -115,7 +115,7 @@ Besides the REPL, Babel offers a command-line tool written as a Node.js package.
 You can download Node.js from their website: https://mjavascript.com/out/node. After installing Node, you'll be able to use the +npm+ command-line tool in your terminal.
 ====
 
-Before getting started we'll create a project directory and a +package.json+ file, which is a manifest used to describe Node.js applications. We'll create a +package.json+ file through the +npm+ CLI as well.
+Before getting started we'll make a project directory and a +package.json+ file, which is a manifest used to describe Node.js applications. We can create the +package.json+ file through the +npm+ CLI.
 
 [source,shell]
 ----
@@ -183,7 +183,7 @@ Together with the packages we've installed in the previous step, a minimal +pack
 
 [NOTE]
 ====
-Any commands enumerated in the +scripts+ object can be executed through +npm run <name>+, which modifies the +$PATH+ environment variable so that we can run the command-line executables found in +babel-cli+ without installing +babel-cli+ globally on our system.
+Any commands enumerated in the +scripts+ object can be executed through +npm run <name>+, which temporarily modifies the +$PATH+ environment variable so that we can run the command-line executables found in +babel-cli+ without installing +babel-cli+ globally on our system.
 ====
 
 If you execute +npm run build+ in your terminal now, you'll note that a +dist/example.js+ file is created. The output file will be identical to our original file, because Babel doesn't make assumptions, and we have to configure it first. Create a +.babelrc+ file next to +package.json+, and write the following JSON in it.
diff --git a/chapters/ch02.asciidoc b/chapters/ch02.asciidoc
index 834bea0..336075c 100644
--- a/chapters/ch02.asciidoc
+++ b/chapters/ch02.asciidoc
@@ -394,8 +394,6 @@ Arrow functions are neat when it comes to defining anonymous functions that shou
 // <- 8
 ----
 
-The next feature we'll analyze is destructuring in assignment. Let's see what that's all about.
-
 === 2.3 Assignment Destructuring
 
 This is one of the most flexible and expressive features in ES6. It's also one of the simplest. It binds properties to as many variables as you need. It works with objects, arrays, and even in +function+ parameter lists. Let's go step by step, starting with objects.
@@ -442,7 +440,7 @@ In a similar fashion, you could mix and match destructuring with regular variabl
 
 [source,javascript]
 ----
-var { pseudonym, name } = character, two = 2
+var { pseudonym } = character, two = 2
 ----
 
 If you want to extract a property named +pseudonym+ but would like to declare it as a variable named +alias+, you can use the following destructuring syntax known as aliasing. Note that you can use +alias+ or any other valid variable name.
@@ -464,13 +462,7 @@ var { metadata: { gender } } = character
 In cases like the previous one, where you have deeply nested properties being destructured, you might be able to convey a property name more clearly if you choose an alias. Consider the next snippet, where a property named +code+ wouldn't have been as indicative of its contents as +colorCode+ could be.
 [source,javascript]
 ----
-var palette = {
-  color: {
-    name: 'Red',
-    code: '#f00'
-  }
-}
-var { color: { code: colorCode } } = palette
+var { metadata: { gender: characterGender } } = character
 ----
 
 The scenario we just saw repeats itself frequently, because properties are often named in the context of their host object. While +palette.color.code+ is perfectly descriptive, +code+ on its own could mean a wide variety of things, and aliases such as +colorCode+ can help you bring context back into the variable name while still using destructuring.
@@ -498,7 +490,7 @@ A destructured declaration accessing a nested property of a parent object that's
 
 [source,javascript]
 ----
-var { batmobile: { gear } } = character
+var { boots: { size } } = character
 // <- Exception
 var { missing } = null
 // <- Exception
@@ -517,9 +509,9 @@ As part of destructuring, you can provide default values for those cases where t
 
 [source,javascript]
 ----
-var { boots = true } = character
+var { boots = { size: 10 } } = character
 console.log(boots)
-// <- true
+// <- { size: 10 }
 ----
 
 Default values can also be provided in nested property destructuring.
@@ -535,20 +527,19 @@ For use in combination with aliases, you should place the alias first, and then
 
 [source,javascript]
 ----
-var { boots: footwear = true } = character
+var { boots: footwear = { size: 10 } } = character
 ----
 
-It's possible to use the computed property names syntax in destructuring patterns. In this case, however, you're required to provide an alias to be used as the variable name. That's because computed property names allow arbitrary expressions and thus the compiler isn't always able to infer a variable name. In the following example we use the +value+ alias, and a computed property name to extract the +scientist+ property from the +person+ object.
+It's possible to use the computed property names syntax in destructuring patterns. In this case, however, you're required to provide an alias to be used as the variable name. That's because computed property names allow arbitrary expressions and thus the compiler wouldn't be able to infer a variable name. In the following example we use the +value+ alias, and a computed property name to extract the +boots+ property from the +character+ object.
 
 [source,javascript]
 ----
-var person = { scientist: true }
-var { ['scient' + 'ist']: value } = person
-console.log(value)
+var { ['boo' + 'ts']: characterBoots } = character
+console.log(characterBoots)
 // <- true
 ----
 
-This flavor of destructuring is probably the least useful, as +value = person[type]+ is easier to read than +{ [type]: value } = person+, as it's a more sequential statement. That being said, the feature could still be useful in some deep destructuring scenarios.
+This flavor of destructuring is probably the least useful, as +characterBoots = character[type]+ is usually simpler than +{ [type]: characterBoots } = character+, as it's a more sequential statement. That being said, the feature is useful when you have properties you want to declare in the object literal, as opposed to using subsequent assignment statements.
 
 That's it, as far as objects go, in terms of destructuring. What about arrays?
 
@@ -760,6 +751,17 @@ function splitDate (date) {
 var [, year, month, day] = splitDate('2015-11-06')
 ----
 
+You'll want to be careful when the regular expression doesn't match, as that returns `null`. Perhaps a better approach would be to test for the failure case before destructuring, as shown in the following bit of code.
+
+[source,javascript]
+----
+var matches = splitDate('2015-11-06')
+if (matches === null) {
+  return
+}
+var [, year, month, day] = matches
+----
+
 Let's turn our attention to spread and rest operators next.
 
 === 2.4 Rest Parameters and Spread Operator
@@ -1069,7 +1071,7 @@ var html = `<article>
 </article>`
 ----
 
-The template we've just prepared would produce output like what's shown in the following snippet of code. Note how spacing was preserved, and how +<li>+ tags are properly indented thanks for how we joined them together using a few spaces.
+The template we've just prepared would produce output like what's shown in the following snippet of code. Note how spacing was preservedfootnote:[When using multi-line template literals, spacing isn't preserved automatically. However, in many cases we can provide just enough indentation to make it work. Be wary of indented code blocks which may result in undesired indentation due to our code block being nested.], and how +<li>+ tags are properly indented thanks for how we joined them together using a few spaces.
 
 [source,html]
 ----
@@ -1182,7 +1184,7 @@ console.log(text)
 // <- 'Hello MAURICE, I am THRILLED to meet you!'
 ----
 
-A decidedly more useful use case would be to sanitize expressions interpolated into your templates, automatically, using a tagged template. Given a template where all expressions are considered user-input, we could use a hypothetical +sanitize+ library to remove HTML tags and similar hazards, preventing cross site scripting (XSS) attacks where users might inject malicious HTML into our websites.
+A decidedly more useful use case would be to sanitize expressions interpolated into your templates, automatically, using a tagged template. Given a template where all expressions are considered user-input, we could use a hypothetical +sanitize+ library to remove HTML tags and similar hazards, preventing cross-site scripting (XSS) attacks where users might inject malicious HTML into our websites.
 
 [source,javascript]
 ----
@@ -1197,7 +1199,7 @@ console.log(html)
 // <- '<div>A malicious comment</div>'
 ----
 
-Phew, that malicious +<iframe>+ almost got us. Rounding out ES6 syntax changes, we have the +let+ and +const+ statements.
+Phew, that malicious `<iframe>` almost got us. Rounding out ES6 syntax changes, we have the `let` and `const` statements.
 
 === 2.6 Let and Const Statements
 
diff --git a/chapters/ch03.asciidoc b/chapters/ch03.asciidoc
index e856dca..706a5ff 100644
--- a/chapters/ch03.asciidoc
+++ b/chapters/ch03.asciidoc
@@ -5,7 +5,7 @@ Now that we've covered the basic improvements to the syntax, we're in good shape
 
 === 3.1 Classes
 
-Many features in ES6 such as destructuring are in fact syntactic sugar, and classes are no exception to that. As we know, JavaScript is a prototype-based language, and classes are syntactic sugar on top of prototypical inheritance. In that sense, JavaScript classes don't introduce any fundamental changes to the language: they're merely a different way of declaring object prototypes.
+JavaScript is a prototype-based language, and classes are mostly syntactic sugar on top of prototypal inheritance. The fundamental difference between prototypal inheritance and classes is that classes can `extend` other classes, making it possible for us to extend the `Array` built-in -- something that was very convoluted before ES6.
 
 The +class+ keyword acts, then, as a device that makes JavaScript more inviting to programmers coming from other paradigms, who might not be all that familiar with prototype chains.
 
@@ -341,7 +341,7 @@ Let's move onto +Symbol+. While not an iteration or flow control mechanism, lear
 
 === 3.2 Symbols
 
-Symbols are a new primitive type in ES6, and the seventh type in JavaScript. It is an unique value type, like strings and numbers. Unlike strings and numbers, symbols don't have a literal representation such as +'text'+ for strings, or +1+ for numbers. The purpose of symbols is primarily to implement protocols. As we'll learn in section 3.3, the iterable protocol uses a symbol to define how objects are iterated.
+Symbols are a new primitive type in ES6, and the seventh type in JavaScript. It is an unique value type, like strings and numbers. Unlike strings and numbers, symbols don't have a literal representation such as +'text'+ for strings, or +1+ for numbers. The purpose of symbols is primarily to implement protocols. For example, the iterable protocol uses a symbol to define how objects are iterated, as we'll learn in section 4.2.
 
 There are three flavors of symbols, and each flavor is accessed in a different way. These are: local symbols, created with the +Symbol+ built-in wrapper object and accessed by storing a reference or via reflection; global symbols, created using another API and shared across code realms; and "well-known" symbols, built into JavaScript and used to define internal language behavior.
 
@@ -442,7 +442,7 @@ Now that we've established how symbols work. What can we use them for?
 
 Symbols could be used by a library to map objects to DOM elements. For example, a library that needs to associate the API object for a calendar to the provided DOM element. Before ES6, there wasn't a clear way of mapping DOM elements to objects. You could add a property to a DOM element pointing to the API, but polluting DOM elements with custom properties is a bad practice. You have to be careful to use property keys that won't be used by other libraries, or worse, by the language itself in the future. That leaves you with using an array lookup table containing an entry for each DOM/API pair. That, however, might be slow in long-running applications where the array lookup table might grow in size, slowing down the lookup operation over time.
 
-Symbols, on the other hand, don't have these problem. They can be used as properties that don't have a risk of clashing with future language features, as they're unique. The following code snippet shows how a symbol could be used to map DOM elements into calendar API objects.
+Symbols, on the other hand, don't have this problem. They can be used as properties that don't have a risk of clashing with future language features, as they're unique. The following code snippet shows how a symbol could be used to map DOM elements into calendar API objects.
 
 [source,javascript]
 ----
@@ -458,7 +458,7 @@ function createCalendar (el) {
 }
 ----
 
-A +WeakMap+ is an ES6 built-in that can be used to efficiently map objects to other objects without using regular properties, symbol properties, or arrays. In contrast with array lookup tables, +WeakMap+ is O(1), just like using symbol properties. The +WeakMap+ couldn't be accessed from outside the library unless explicitly exposed, unlike with symbols which can be accessed through +Object.getOwnPropertySymbols+. We'll explore +WeakMap+ in chapter 5, alongside other ES6 collection built-ins.
+There is an ES6 built-in -- the +WeakMap+ -- that can be used to uniquely map objects to other objects without using regular properties, symbol properties, or arrays. In contrast with array lookup tables, +WeakMap+ is O(1), just like using symbol properties. The +WeakMap+ couldn't be accessed from outside the library unless explicitly exposed, unlike with symbols which can be accessed through +Object.getOwnPropertySymbols+. We'll explore +WeakMap+ in chapter 5, alongside other ES6 collection built-ins.
 
 ===== Defining Protocols through Symbols
 
@@ -820,7 +820,7 @@ We dive deeper into object rest and spread in chapter 9.
 
 ==== 3.3.2 Comparing objects with +Object.is+
 
-The +Object.is+ method is a slightly different version of the strict equality comparison operator, +===+. For the most part, +Object.is(a, b)+ is equal to +a === b+. There are two differences: the case of +NaN+ and the case of +-0+ and ++0+.
+The +Object.is+ method is a slightly different version of the strict equality comparison operator, +===+. For the most part, +Object.is(a, b)+ is equal to +a === b+. There are two differences: the case of +NaN+ and the case of +-0+ and ++0+. This algorithm is referred to as `SameValue` in the ECMAScript specification.
 
 When +NaN+ is compared to +NaN+, the strict equality comparison operator returns +false+ because +NaN+ is not equal to itself. The +Object.is+ method, however, returns +true+ in this special case.
 
@@ -865,7 +865,7 @@ const baseCat = { type: 'cat', legs: 4 }
 const cat = Object.setPrototypeOf({ name: 'Milanesita' }, baseCat)
 ----
 
-Note however that there are serious performance implications when using `Obect.setPrototypeOf` as opposed to `Object.create`, and some careful consideration is in order before you decide to go ahead and sprinkle `Object.setPrototypeOf` all over a codebase.
+Note however that there are serious performance implications when using `Object.setPrototypeOf` as opposed to `Object.create`, and some careful consideration is in order before you decide to go ahead and sprinkle `Object.setPrototypeOf` all over a codebase.
 
 .Performance issues
 [WARNING]
diff --git a/chapters/ch04.asciidoc b/chapters/ch04.asciidoc
index 14230dc..c89f99c 100644
--- a/chapters/ch04.asciidoc
+++ b/chapters/ch04.asciidoc
@@ -11,7 +11,7 @@ Promises can be vaguely defined as "a proxy for a value that will eventually bec
 
 ==== 4.1.1 Getting Started with Promises
 
-As an example, let's take a look at the upcoming browser +fetch+ API. This API is a simplification of +XMLHttpRequest+. It aims to be super simple to use for the most basic use cases: making a +GET+ request against an HTTP resource. It provides an extensive API that caters to advanced use cases, but that's not our focus for now. In its most basic incarnation, you can make a +GET /items+ HTTP request using a piece of code like the following.
+As an example, let's take a look at the new +fetch+ API for the browser. This API is a simplification of +XMLHttpRequest+. It aims to be super simple to use for the most basic use cases: making a +GET+ request against an HTTP resource. It provides an extensive API that caters to advanced use cases, but that's not our focus for now. In its most basic incarnation, you can make a +GET /items+ HTTP request using a piece of code like the following.
 
 [source,javascript]
 ----
@@ -300,7 +300,11 @@ Here is an enumeration of what is going on as that piece of code is executed.
 8. The +p3+ promise from +p2.catch+ is fulfilled, because it doesn't produce an error or result in a rejected promise
 9. Because +p3+ was fulfilled, the +p3.catch+ is never followed. The +p3.then+ branch would've been used instead
 
-You should think of promises as a tree structure. This bears repetition: you should think of promises as a tree structurefootnote:[I wrote an online visualization tool called Promisees where you can see the tree structure underlying a Promise chain: https://mjavascript.com/out/promisees.]. It all starts with a single promise, which we'll next learn how to construct. Then you add branches with +.then+ or +.catch+. You can tack as many +.then+ or +.catch+ calls as you want onto each branch, creating new branches, and so on.
+You should think of promises as a tree structure. This bears repetition: you should think of promises as a tree structurefootnote:[I wrote an online visualization tool called Promisees where you can see the tree structure underlying a Promise chain: https://mjavascript.com/out/promisees.].
+
+image::../images/c04g02-promise-chain.png["Promisees can help us visualize how the fetch promise is fulfilled, but p2 is rejected, thus triggering any rejection reactions attached to it. Given p3 is fulfilled, rejection reactions like p4 are never executed."]
+
+It all starts with a single promise, which we'll next learn how to construct. Then you add branches with +.then+ or +.catch+. You can tack as many +.then+ or +.catch+ calls as you want onto each branch, creating new branches, and so on.
 
 ==== 4.1.3 Creating a Promise From Scratch
 
@@ -555,18 +559,21 @@ The method assigned to +Symbol.iterator+ must return an object that adheres to t
 - +value+ is the current item in the sequence
 - +done+ is a boolean indicating whether the sequence has ended
 
-Let's use the following piece of code as a crutch to understand the concepts behind iteration protocols. We're turning the +sequence+ object into an iterable by adding a +Symbol.iterator+ property. The iterable returns an iterator object. Each time +next+ is asked for the following value in the sequence, an element from the +items+ array is provided, until there's no more +items+ left.
+Let's use the following piece of code as a crutch to understand the concepts behind iteration protocols. We're turning the +sequence+ object into an iterable by adding a +Symbol.iterator+ property. The iterable returns an iterator object. Each time +next+ is asked for the following value in the sequence, an element from the +items+ array is provided. When +i+ goes beyond the last index on the +items+ array, we return +done: true+, indicating the sequence has ended.
 
 [source,javascript]
 ----
+const items = ['i', 't', 'e', 'r', 'a', 'b', 'l', 'e']
 const sequence = {
   [Symbol.iterator]() {
-    const items = ['i', 't', 'e', 'r', 'a', 'b', 'l', 'e']
+    let i = 0
     return {
-      next: () => ({
-        done: items.length === 0,
-        value: items.shift()
-      })
+      next() {
+        const value = items[i]
+        i++
+        const done = i > items.length
+        return { value, done }
+      }
     }
   }
 }
@@ -727,7 +734,7 @@ This sort of abstraction of complexity into another function often helps keep co
 ====
 Iterators don't have any knowledge that the sequences they produce are infinite. In a similar situation to the famous halting problem, there is no way of knowing whether the sequence is infinite or not in code.
 
-image::../images/c04g02-halting-problem.png["The halting problem depicted in an XKCD comic: https://mjavascript.com/out/xkcd-1266."]
+image::../images/c04g03-halting-problem.png["The halting problem depicted in an XKCD comic: https://mjavascript.com/out/xkcd-1266."]
 
 You typically have a good idea of whether a sequence is infinite or not. Whenever you have an infinite sequence it's up to you to add an escape condition that ensures the program won't crash in an attempt to loop over every single value in the sequence. While +for..of+ won't run into the problem unless there's no escape condition, using mechanisms such as spread or +Array.from+ would immediately result in the program crashing into an infinite loop in the case of infinite sequences.
 ====
@@ -937,7 +944,7 @@ function shuffleSongs (songs) {
 }
 ----
 
-Lastly, we'd have to pass in the +shuffle+ flag as +true+ if we wanted to shuffle songs in each repeat cycle. Otherwise, songs would be reproduced in the original order provided by the user. Here again we've abstracted away something that usually would involve many lines of code used to decide what song comes next into a neatly decoupled function that's only concerned with producing a sequence of songs to be reproduced by a song player.
+Lastly, we'd have to pass in the +shuffle+ flag as +true+ if we wanted to shuffle songs in the playlist. Otherwise, songs would be reproduced in the original order provided by the user. Here again we've abstracted away something that usually would involve many lines of code used to decide what song comes next into a neatly decoupled function that's only concerned with producing a sequence of songs to be reproduced by a song player.
 
 [source,javascript]
 ----
@@ -945,7 +952,7 @@ console.log([...playlist(['a', 'b'], 3, true)])
 // <- ['a', 'b', 'b', 'a', 'a', 'b']
 ----
 
-You may have noticed how the `playlist` function doesn't necessarily need to concern itself with the sort order of the songs passed to it. A better design choice may well be to extract shuffling into the calling code. If we kept the original +playlist+ code we had earlier, we could use code like the following to obtain a shuffled song collection.
+You may have noticed how the `playlist` function doesn't necessarily need to concern itself with the sort order of the songs passed to it. A better design choice may well be to extract shuffling into the calling code. If we kept the original +playlist+ function without a +shuffle+ parameter, we could still use a snippet like the following to obtain a shuffled song collection.
 
 [source,javascript]
 ----
@@ -1134,7 +1141,7 @@ Whenever +.next()+ is called on a generator, there are four different kinds of "
 - A +yield+ expression returning the next value in the sequence
 - A +return+ statement returning the last value in the sequence
 - A +throw+ statement halts execution in the generator entirely
-- Reaching the end of the generator function signals +{ done: true }+
+- Reaching the end of the generator function signals +{ done: true }+, as the function implicitly returns +undefined+
 
 Once the +g+ generator ended iterating over a sequence, subsequent calls to +g.next()+ will have no effect and just return +{ done: true }+. The following code snippet demonstrates the idempotence we can observe when calling +g.next+ repeatedly once a sequence has ended.
 
@@ -2211,7 +2218,7 @@ async function* fetchInterval(duration, ...params) {
 }
 ----
 
-When stepped over, async generators return objects with a +{ next, return, throw }+ signature, whose methods return promises for +{ next, done }+. This is in contrast with regular generators which return +{ next, done }+ directly.
+When stepped over, async generators return objects with a +{ next, return, throw }+ signature, whose methods return promises for +{ value, done }+. This is in contrast with regular generators which return +{ value, done }+ directly.
 
 You can consume the +fetchInterval+ async generator in exactly the same way you could consume the object-based +interval+ async iterator. The following example consumes the +fetchInterval+ generator to poll an +/api/status+ HTTP resource and leverage its JSON response. After each step ends, we wait for a second and repeat the process.
 
diff --git a/chapters/ch05.asciidoc b/chapters/ch05.asciidoc
index 79b3406..eb7d920 100644
--- a/chapters/ch05.asciidoc
+++ b/chapters/ch05.asciidoc
@@ -20,7 +20,8 @@ add('woofmark', { description: 'Markdown and WYSIWYG editor' })
 There's several problems with this approach, outlined below.
 
 - Security issues where user-provided keys like `__proto__`, +toString+, or anything in +Object.prototype+ break expectations and make interaction with this kind of hash-map data structures more cumbersome
-- Iteration over list items is verbose with +Object.keys(registry).forEach+
+- When iterating using +for..in+ we need to rely on +Object#hasOwnProperty+ to make sure properties aren't inherited
+- Iteration over list items with +Object.keys(registry).forEach+ is also verbose
 - Keys are limited to strings, making it hard to create hash-maps where you'd like to index values by DOM elements or other non-string references
 
 The first problem could be fixed using a prefix, and being careful to always get or set values in the hash-map through functions that add those prefixes, to avoid mistakes.
@@ -109,11 +110,11 @@ map.has('jquery')
 // <- false
 ----
 
-Earlier, we pointed out that maps don't cast keys the way traditional objects do. This is typically an advantage, but you need to keep in mind that they won't be treated the same when querying the map, either.
+Earlier, we pointed out that maps don't cast keys the way traditional objects do. This is typically an advantage, but you need to keep in mind that they won't be treated the same when querying the map, either. The following example uses the +Map+ constructor which takes an iterable of key value pairs and then illustrates how maps don't cast their keys to strings.
 
 [source,javascript]
 ----
-const map = new Map([[1, 'a']])
+const map = new Map([[1, 'the number one']])
 map.has(1)
 // <- true
 map.has('1')
@@ -273,17 +274,21 @@ console.log([...map])
 // <- [['a', 3]]
 ----
 
-In ES6 maps, `NaN` becomes a "corner-case" that gets treated as a value that's equal to itself, even though the `NaN === NaN` expression evaluates to `false`. A number of ECMAScript features introduced in ES6 and later use a different comparison algorithm than that of ES5 and earlier where `NaN` is equal to `NaN`, although `NaN !== NaN`; and `+0` is different from `-0`, even though `+0 === -0`. The following piece of code shows how even though `NaN` is typically evaluated to be different than itself, `Map` considers `NaN` to be a constant value that's always the same.
+ES6 maps compare keys using an algorithm called `SameValueZero` in the specification, where `NaN` equals `NaN` but `-0` equals `+0`. The following piece of code shows how even though `NaN` is typically evaluated to be different than itself, `Map` considers `NaN` to be a constant value that's always the same.
 
 [source,javascript]
 ----
 console.log(NaN === NaN)
 // <- false
+console.log(-0 === +0)
+// <- true
 const map = new Map()
-map.set(NaN, 'a')
-map.set(NaN, 'b')
+map.set(NaN, 'one')
+map.set(NaN, 'two')
+map.set(-0, 'three')
+map.set(+0, 'four')
 console.log([...map])
-// <- [[NaN, 'b']]
+// <- [[NaN, 'two'], [0, 'four']]
 ----
 
 When you iterate over a +Map+, you are actually looping over its +.entries()+. That means that you don't need to explicitly iterate over +.entries()+. It'll be done on your behalf anyways: +map[Symbol.iterator]+ points to +map.entries+. The +.entries()+ method returns an iterator for the key/value pairs in the map.
@@ -432,9 +437,11 @@ map.set(Symbol(), 2)
 // <- TypeError
 ----
 
-In exchange for having a more limited feature set, +WeakMap+ key references are weakly held, meaning that the objects referenced by +WeakMap+ keys are subject to garbage collection if there are no references to them -- other than weak references. This kind of behavior is useful when you have metadata about a +person+, for example, but you want the +person+ to be garbage collected when and if the only reference back to +person+ is their metadata. You can now keep that metadata in a +WeakMap+ using +person+ as the key.
+In exchange for having a more limited feature set, +WeakMap+ key references are weakly held, meaning that the objects referenced by +WeakMap+ keys are subject to garbage collection if there are no references to them -- other than weak references. This kind of behavior is useful when you have metadata about a +person+, for example, but you want the +person+ to be garbage collected when and if the only reference back to +person+ is their associated metadata. You can now keep that metadata in a +WeakMap+ using +person+ as the key.
+
+In that sense, a +WeakMap+ is most useful when the component maintaining it doesn't own the mapped objects, but wants to assign its own information to them without modifying the original objects or their lifecycle; letting memory be reclaimed when, for example, a DOM node is removed from the document.
 
-With +WeakMap+, you are still able to provide an iterable for initialization.
+To initialize a +WeakMap+, you are able to provide an iterable through the constructor. This should be a list of key value pairs, just like with +Map+.
 
 [source,javascript]
 ----
@@ -564,9 +571,9 @@ console.log(set.keys === set.values)
 
 In a similar fashion to `Map` and `WeakMap`, `WeakSet` is the weak version of `Set` that can't be iterated over. The values in a `WeakSet` must be unique object references. If nothing else is referencing a `value` found in a `WeakSet`, it'll be subject to garbage collection.
 
-Much like in `WeakMap`, you can only `.add`, `.delete`, and check if `WeakSet#has` a given `value`. Just like in `Set`, there's no `.get` because sets are one-dimensional.
+You can only `.set`, `.delete`, and check if the `WeakSet` `.has` a given `value`. Just like in `Set`, there's no `.get` because sets are one-dimensional.
 
-We aren't allowed to add primitive values such as strings or symbols to a +WeakSet+.
+Like with `WeakMap`, we aren't allowed to add primitive values such as strings or symbols to a +WeakSet+.
 
 [source,javascript]
 ----
diff --git a/chapters/ch07.asciidoc b/chapters/ch07.asciidoc
index fb81a7a..85ad8d0 100644
--- a/chapters/ch07.asciidoc
+++ b/chapters/ch07.asciidoc
@@ -662,7 +662,7 @@ function log2 (value) {
 }
 ----
 
-Note that the polyfilled version won't be as precise as +Math.log2+, as demonstrated in the following example. Keep in mind that the +<<+ operator performs a "bitwise left shift"footnoteref:[bitwise-shift,Definition on MDN: https://mjavascript.com/out/bitwise-shift.].
+Note that the polyfilled version won't be as precise as +Math.log2+, as demonstrated in the following example.
 
 [source,javascript]
 ----
@@ -672,6 +672,22 @@ Math.log2(1 << 29)
 // <- 29
 ----
 
+The +<<+ operator performs a "bitwise left shift"footnoteref:[bitwise-shift,Definition on MDN: https://mjavascript.com/out/bitwise-shift.]. In this operation, the bits on the binary representation of the left hand side number are shifted as many places to the left as indicated in the right hand side of the operation. The following couple of examples show how shifting works, using the binary literal notation introduced in section 7.1.1.
+
+[source]
+----
+0b00000001 // 1
+0b00000001 << 2 // shift bits two places to the left
+0b00000100 // 4
+----
+
+[source]
+----
+0b00001101 // 1
+0b00001101 << 4 // shift bits four places to the left
+0b11010000 // 208
+----
+
 ==== 7.2.8 Trigonometric Functions
 
 The +Math+ object is getting trigonometric functions in ES6.
@@ -693,7 +709,7 @@ Math.hypot(1, 2, 3)
 // <- 3.741657386773941, the square root of (1*1 + 2*2 + 3*3)
 ----
 
-We could polyfill +Math.hypot+ by performing these operations manually. We can use +Math.sqrt+ to compute the square root and +Array#reduce+footnote:[You can go deeper into functional Array methods by reading my "Fun with Native Arrays" article: https://mjavascript.com/out/native-arrays.], combined with the spread operator, to sum the squares.
+We could polyfill +Math.hypot+ by performing these operations manually. We can use +Math.sqrt+ to compute the square root and +Array#reduce+, combined with the spread operator, to sum the squares.footnote:[You can go deeper into functional Array methods by reading my "Fun with Native Arrays" article: https://mjavascript.com/out/native-arrays.]
 
 [source,javascript]
 ----
@@ -901,7 +917,7 @@ This handy method allows you to repeat a string +count+ times.
 // <- ``
 ----
 
-The provided +count+ should be a positive and finite number.
+The provided +count+ should be a non-negative finite number.
 
 [source,javascript]
 ----
diff --git a/chapters/ch08.asciidoc b/chapters/ch08.asciidoc
index 7523428..64548ed 100644
--- a/chapters/ch08.asciidoc
+++ b/chapters/ch08.asciidoc
@@ -160,7 +160,7 @@ As we explored the CommonJS module system, you might've noticed how the API is s
 
 ==== 8.2.1 Strict Mode
 
-In the ES6 module system, strict mode is turned on by default. Strict mode is a featurefootnote:[Read a comprehensive article about strict mode on Mozilla's MDN: https://mjavascript.com/out/strict-mode.] that disallows bad parts of the language, and turns some silent errors into loud exceptions being thrown. Taking into account these disallowed features, compilers can make optimizations making JavaScript runtime faster and safer.
+In the ES6 module system, strict mode is turned on by default. Strict mode is a featurefootnote:[Read a comprehensive article about strict mode on Mozilla's MDN: https://mjavascript.com/out/strict-mode.] that disallows bad parts of the language, and turns some silent errors into loud exceptions being thrown. Taking into account these disallowed features, compilers can enable optimizations making JavaScript runtime faster and safer.
 
 - Variables must be declared
 - Function parameters must have unique names
@@ -168,7 +168,7 @@ In the ES6 module system, strict mode is turned on by default. Strict mode is a
 - Assignment to read-only properties results in errors being thrown
 - Octal numbers like +00840+ are syntax errors
 - Attempts to +delete+ undeletable properties throw an error
-- +delete prop+ is a syntax error, instead of assuming +delete global[prop]+
+- +delete prop+ is a syntax error, instead of assuming +delete global.prop+
 - +eval+ doesn't introduce new variables into its surrounding scope
 - +eval+ and +arguments+ can't be bound or assigned to
 - +arguments+ doesn't magically track changes to method parameters
@@ -390,7 +390,7 @@ We've now covered every way in which we can expose an API in ES6 modules. Let's
 
 ==== 8.2.3 +import+ Statements
 
-We can load a module from another one using +import+ statements. The way modules are loaded is implementation-specific, that is: it's not defined by the specification. No browsers have implemented module loading as of this writing. We can write spec-compliant ES6 code today while smart people figure out how to deal with module loading in browsers.
+We can load a module from another one using +import+ statements. The way modules are loaded is implementation-specific, that is: it's not defined by the specification. We can write spec-compliant ES6 code today while smart people figure out how to deal with module loading in browsers.
 
 Compilers like Babel are able to concatenate modules with the aid of a module system like CommonJS. That means +import+ statements in Babel mostly follow the same semantics as +require+ statements in CommonJS.
 
diff --git a/chapters/ch09.asciidoc b/chapters/ch09.asciidoc
index 980970b..a3b28de 100644
--- a/chapters/ch09.asciidoc
+++ b/chapters/ch09.asciidoc
@@ -1,7 +1,7 @@
 [[practical-considerations]]
 == Practical Considerations
 
-JavaScript is an ever-evolving language. Its development rhythm has had different paces throughout the years, entering a high velocity phase with the introduction of ES5. Thus far, this book has taught you about dozens of language features and syntax changes introduced in ES6, and a few that came out afterwards, in ES2016 and ES2017.
+JavaScript is an ever-evolving language. Its development rhythm has had different paces throughout the years, entering a high-velocity phase with the introduction of ES5. Thus far, this book has taught you about dozens of language features and syntax changes introduced in ES6, and a few that came out afterwards, in ES2016 and ES2017.
 
 Reconciling all of these new features with our existing ES5 knowledge may seem like a daunting task: what features should we take advantage of, and how? This chapter aims to rationalize the choices we have to make when considering whether to use specific ES6 features.
 
@@ -265,7 +265,7 @@ When it comes to the +suitKind+ variable, a template literal with no interpolati
 
 Once we stop compiling template literals down to quoted strings, we can expect optimizing compilers to be able to interpet them as such with negligible slowdown.
 
-Another often-cited concern is syntax: as of this writing, we can't use backtick strings in JSON, object keys, +import+ declarations, or strict mode statements.
+Another often-cited concern is syntax: as of this writing, we can't use backtick strings in JSON, object keys, +import+ declarations, or strict mode directives.
 
 The first statement in the following snippet of code demonstrates that a serialized JSON object couldn't represent strings using backticks. As shown on the second line, we can certainly declare an object using template literals and then serialize that object as JSON. By the time +JSON.stringify+ is invoked, the template literal has evaluated to a quoted string.
 
@@ -501,17 +501,33 @@ In the following example, array destructuring helps us omit the whole match and
 
 [source,javascript]
 ----
-const rnumber = /(\d+)\.(\d+)/
-const [, integer, fractional] = `1234.56`.match(rnumber)
-// <- integer: `1234`, fractional: `56`
+function getNumberParts (number) {
+  const rnumber = /(\d+)\.(\d+)/
+  const matches = number.match(rnumber)
+  if (matches === null) {
+    return null
+  }
+  const [, integer, fractional] = number.match(rnumber)
+  return { integer, fractional }
+}
+getNumberParts(`1234.56`)
+// <- { integer: `1234`, fractional: `56` }
 ----
 
 The spread operator could be used to pick up every captured group, as part of destructuring the result of +.match+.
 
 [source,javascript]
 ----
-const rnumber = /(\d+)\.(\d+)/
-const [, ...captures] = `1234.56`.match(rnumber)
+function getNumberParts (number) {
+  const rnumber = /(\d+)\.(\d+)/
+  const matches = number.match(rnumber)
+  if (matches === null) {
+    return null
+  }
+  const [, ...captures] = number.match(rnumber)
+  return captures
+}
+getNumberParts(`1234.56`)
 // <- [`1234`, `56`]
 ----
 
diff --git a/images/c04g02-promise-chain.png b/images/c04g02-promise-chain.png
new file mode 100644
index 0000000..ef013fc
Binary files /dev/null and b/images/c04g02-promise-chain.png differ
diff --git a/images/c04g02-halting-problem.png b/images/c04g03-halting-problem.png
similarity index 100%
rename from images/c04g02-halting-problem.png
rename to images/c04g03-halting-problem.png