@mike yes that’s true, but issues with blocking-code javascript data-structures/algorithms are rarely the reason web-projects fail. they fail largely due to unresolvable integration-level io/workflow issues (that are unique only to javascript). block-scoping fixes the insignificant former, while exacerbating the more pressing latter, by encouraging people to pollute variable-declarations all-over-the-place; making it harder to discern-and-debug which ones are critical io-related closure-variables and which ones are not.
data-structure and algorithmic coding-skills are rarely all that useful in javascript (just throw sqlite3 at it and it will likely go away). integration-level debugging-skills (and knowledge of which coding design-patterns to employ to make io easier to debug) are far more valuable and correlable to successfully shipping a web-project. > On Mar 22, 2018, at 3:47 AM, Mike Samuel <[email protected]> wrote: > > > > On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton <[email protected] > <mailto:[email protected]>> wrote: > Because block-level scoping is a very good way to avoid certain bugs and is > easier to reason about. Especially when considering project successors. > > +1. function-scoped variables in loop bodies caused tons of bugs before > let-scoped variables and were a main motivating case. > > var i; > for (i = 0; i < arr.length; ++i) { > f(function () { /* Do something with */ arr[i]; }); > } > > vs > > for (let i = 0; i < arr.length; ++i) { > f(function () { /* Do something with */ arr[i]; }); > } > > Yes, linters got pretty good at finding uses of closed-over variables > modified in a loop, but the workarounds were not ideal. > > var i; > for (i = 0; i < arr.length; ++i) { > f(function (i) { return function () { /* Do something with */ arr[i]; } > }(i)); > } > > Block scoping is just better for code that uses loops, variables, and > function expressions. >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
