Fun fact: you'd be surprised how many non-trivial JS stuff there is. If you've ever used jQuery selectors, you've used a selector engine implemented in JS [1], which uses quite a few advanced data structure and algorithm techniques. Not all JavaScript is inherently async, nor does it need to be. Updating the UI in larger web apps can't be easily done synchronously, and it requires significant familiarity with data structures. The alternative is to do it all server side, but then you're wasting resources doing what your client could do just as easily - it doesn't necessarily have all the data, but it certainly has a working CPU and RAM chip. At smaller scale like with typical business websites, it doesn't matter, but at even mid-level startup scale, it drives server costs down quite a bit. (If you can move 15% of the RAM/CPU workload to the client without affecting perceptible performance, that's 15% fewer servers/data clusters you need. For Facebook and Google, that could mean one less data center they have to build and maintain.)
Also, little language annoyances are themselves worth tackling as real problems. Programming languages aren't just made to solve problems. They are also themselves an art form unto themselves. [1]: https://github.com/jquery/sizzle/blob/master/src/sizzle.js ----- Isiah Meadows [email protected] Looking for web consulting? Or a new website? Send me an email and we can get started. www.isiahmeadows.com On Wed, Mar 21, 2018 at 3:56 PM, kai zhu <[email protected]> wrote: > @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]> > 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 > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
