advanced functions main sync

Author: bogdanbacosca

1-js/06-advanced-functions/01-recursion/01-sum-to/solution.md

@@ -37,4 +37,4 @@ P.S. Naturally, the formula is the fastest solution. It uses only 3 operations f
 
 The loop variant is the second in terms of speed. In both the recursive and the loop variant we sum the same numbers. But the recursion involves nested calls and execution stack management. That also takes resources, so it's slower.
 
-P.P.S. Some engines support the "tail call" optimization: if a recursive call is the very last one in the function (like in `sumTo` above), then the outer function will not need to resume the execution, so the engine doesn't need to remember its execution context. That removes the burden on memory, so counting `sumTo(100000)` becomes possible. But if the JavaScript engine does not support tail call optimization (most of them don't), there will be an error: maximum stack size exceeded, because there's usually a limitation on the total stack size.
+P.P.S. Some engines support the "tail call" optimization: if a recursive call is the very last one in the function, with no other calculations performed, then the outer function will not need to resume the execution, so the engine doesn't need to remember its execution context. That removes the burden on memory. But if the JavaScript engine does not support tail call optimization (most of them don't), there will be an error: maximum stack size exceeded, because there's usually a limitation on the total stack size.

1-js/06-advanced-functions/01-recursion/article.md

@@ -61,7 +61,7 @@ When `pow(x, n)` is called, the execution splits into two branches:
               if n==1  = x
              /
 pow(x, n) =
-             \       
+             \
               else     = x * pow(x, n - 1)
 ```
 
@@ -285,7 +285,7 @@ The iterative `pow` uses a single context changing `i` and `result` in the proce
 
 **Any recursion can be rewritten as a loop. The loop variant usually can be made more effective.**
 
-...But sometimes the rewrite is non-trivial, especially when function uses different recursive subcalls depending on conditions and merges their results or when the branching is more intricate. And the optimization may be unneeded and totally not worth the efforts.
+...But sometimes the rewrite is non-trivial, especially when a function uses different recursive subcalls depending on conditions and merges their results or when the branching is more intricate. And the optimization may be unneeded and totally not worth the efforts.
 
 Recursion can give a shorter code, easier to understand and support. Optimizations are not required in every place, mostly we need a good code, that's why it's used.
 
@@ -535,7 +535,7 @@ Terms:
     list = { value, next -> list }
     ```
 
-    Trees like HTML elements tree or the department tree from this chapter are also naturally recursive: they branch and every branch can have other branches.
+    Trees like HTML elements tree or the department tree from this chapter are also naturally recursive: they have branches and every branch can have other branches.
 
     Recursive functions can be used to walk them as we've seen in the `sumSalary` example.
 

1-js/06-advanced-functions/01-recursion/recursive-salaries.svg

@@ -23,7 +23,7 @@ function sum(a, b) {
 alert( sum(1, 2, 3, 4, 5) );
 ```
 
-There will be no error because of "excessive" arguments. But of course in the result only the first two will be counted.
+There will be no error because of "excessive" arguments. But of course in the result only the first two will be counted, so the result in the code above is `3`.
 
 The rest of the parameters can be included in the function definition by using three dots `...` followed by the name of the array that will contain them. The dots literally mean "gather the remaining parameters into an array".
 

1-js/06-advanced-functions/02-rest-parameters-spread/article.md

@@ -1,4 +1,6 @@
+importance: 5
 
+---
 # Function in if
 
 Look at the code. What will be the result of the call at the last line?

1-js/06-advanced-functions/03-closure/5-function-in-if/task.md

@@ -58,7 +58,7 @@ alert(test); // ReferenceError: test is not defined
 
 The same thing for loops: `var` cannot be block- or loop-local:
 
-```js
+```js run
 for (var i = 0; i < 10; i++) {
   var one = 1;
   // ...
@@ -170,7 +170,7 @@ That's best demonstrated with an example:
 
 ```js run
 function sayHi() {
-  alert(phrase);  
+  alert(phrase);
 
 *!*
   var phrase = "Hello";

1-js/06-advanced-functions/04-var/article.md

@@ -25,7 +25,7 @@ var gVar = 5;
 alert(window.gVar); // 5 (became a property of the global object)
 ```
 
-The same effect have function declarations (statements with `function` keyword in the main code flow, not function expressions).
+Function declarations have the same effect (statements with `function` keyword in the main code flow, not function expressions).
 
 Please don't rely on that! This behavior exists for compatibility reasons. Modern scripts use [JavaScript modules](info:modules) where such a thing doesn't happen.
 

1-js/06-advanced-functions/05-global-object/article.md

@@ -27,7 +27,7 @@ Usually, that's a function. For historical reasons, a string of code can be pass
 : The delay before run, in milliseconds (1000 ms = 1 second), by default 0.
 
 `arg1`, `arg2`...
-: Arguments for the function (not supported in IE9-)
+: Arguments for the function
 
 For instance, this code calls `sayHi()` after one second:
 
@@ -102,7 +102,7 @@ As we can see from `alert` output, in a browser the timer identifier is a number
 
 Again, there is no universal specification for these methods, so that's fine.
 
-For browsers, timers are described in the [timers section](https://www.w3.org/TR/html5/webappapis.html#timers) of HTML5 standard.
+For browsers, timers are described in the [timers section](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers) of HTML Living Standard.
 
 ## setInterval
 
@@ -232,7 +232,7 @@ setTimeout(function() {...}, 100);
 
 For `setInterval` the function stays in memory until `clearInterval` is called.
 
-There's a side-effect. A function references the outer lexical environment, so, while it lives, outer variables live too. They may take much more memory than the function itself. So when we don't need the scheduled function anymore, it's better to cancel it, even if it's very small.
+There's a side effect. A function references the outer lexical environment, so, while it lives, outer variables live too. They may take much more memory than the function itself. So when we don't need the scheduled function anymore, it's better to cancel it, even if it's very small.
 ````
 
 ## Zero delay setTimeout
@@ -256,7 +256,7 @@ The first line "puts the call into calendar after 0ms". But the scheduler will o
 There are also advanced browser-related use cases of zero-delay timeout, that we'll discuss in the chapter <info:event-loop>.
 
 ````smart header="Zero delay is in fact not zero (in a browser)"
-In the browser, there's a limitation of how often nested timers can run. The [HTML5 standard](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers) says: "after five nested timers, the interval is forced to be at least 4 milliseconds.".
+In the browser, there's a limitation of how often nested timers can run. The [HTML Living Standard](https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html#timers) says: "after five nested timers, the interval is forced to be at least 4 milliseconds.".
 
 Let's demonstrate what it means with the example below. The `setTimeout` call in it re-schedules itself with zero delay. Each call remembers the real time from the previous one in the `times` array. What do the real delays look like? Let's see:
 
@@ -297,6 +297,6 @@ Please note that all scheduling methods do not *guarantee* the exact delay.
 For example, the in-browser timer may slow down for a lot of reasons:
 - The CPU is overloaded.
 - The browser tab is in the background mode.
-- The laptop is on battery.
+- The laptop is on battery saving mode.
 
 All that may increase the minimal timer resolution (the minimal delay) to 300ms or even 1000ms depending on the browser and OS-level performance settings.

1-js/06-advanced-functions/08-settimeout-setinterval/article.md

@@ -8,7 +8,7 @@ Create a "throttling" decorator `throttle(f, ms)` -- that returns a wrapper.
 
 When it's called multiple times, it passes the call to `f` at maximum once per `ms` milliseconds.
 
-The difference with debounce is that it's completely different decorator:
+Compared to the debounce decorator, the behavior is completely different:
 - `debounce` runs the function once after the "cooldown" period. Good for processing the final result.
 - `throttle` runs it not more often than given `ms` time. Good for regular updates that shouldn't be very often.
 

1-js/06-advanced-functions/09-call-apply-decorators/04-throttle/task.md

@@ -202,7 +202,7 @@ for (let key in user) {
 }
 ```
 
-JavaScript libraries also provide functions for convenient mass binding , e.g. [_.bindAll(object, methodNames)](http://lodash.com/docs#bindAll) in lodash.
+JavaScript libraries also provide functions for convenient mass binding , e.g. [_.bindAll(object, methodNames)](https://lodash.com/docs#bindAll) in lodash.
 ````
 
 ## Partial functions