I absolutely agree with you about the importance of first-class functions and closures for async programming.
However, I disagree with your number (1). First, you shouldn't have to use "var self = this;" very often, unless this is your preferred style. Many JS libraries will let you pass in the context as the final argument in a function call. And if you can't do this, you should look to `bind` and `apply`, they're very handy for handling contexts [1].
I do strongly agree with your (2). But if I'm not mistaken, the latest versions of many browsers do support block scope already. I know Chrome does, and Firefox and Edge may as well.
1. http://javascriptissexy.com/javascript-apply-call-and-bind-m...
Re:A love letter to jQuery
by DonHopkins on Saturday February 27, 2016 @07:37PM
(#11189181)
As often as I program in JavaScript myself, and warn other people about the "this" binding problem (it's really hard to explain to newbies, but important), I get nailed by it all the time myself. I just can't seem to remember to go out of my way every time and use "var self = this;" or call bind, and it's quite easy to miss it when visually inspecting code. It's the first thing I look for when things goes inexplicably wrong. The second thing is variables changing out from under closures in loops.
I am looking forward to the time that most major browsers support => and let.
1) First order functions that you can pass around.
2) The fact that those functions can be closures over the local scope, so it's easy to pick up from where you left off.
Two big mistakes in the design of JavaScript that work against easy "asynchronous programming" are:
1) That "this" is not lexically bound in the local scope (technically it's a magic "keyword" that's dynamically bound by the interpreter), even though in most cases capturing "this" lexically is what you really mean to do.
To mitigate that problem, you have to do silly stuff like "var self = this;" to copy dynamically scoped "this" into lexically scoped "self".
2) Each { block } doesn't have its own variable scope, so variables you bind inside loops that repeatedly create closures (like callbacks for a list of menu items) have their value changed out from under them to the last loop iteration when those closures are called later on.
To mitigate that problem you have to wrap another function(){ ... }(); around the loop body to capture the values for each loop individually.
Both problems cause subtle hard to find bugs, even when you know about them and are expecting them and programming defensively to avoid them. And both problems were bad naive design decisions that many other languages had previously gotten right.
But modern bleeding edge JavaScript now has "=>" fat arrow functions that bind this lexically, and "let" that declares block scope variables. (But that's not supported in all browser yet.)
Yay for progress! Worse may be better, but once you've wiped out the competition and taken over the world, there's no reason to keep it worse on purpose.