Two important things about JavaScript that enables easy &quot;asynchronous programming&quot; are:<p>1) First order functions that you can pass around.<p>2) The fact that those functions can be closures over the local scope, so it&#x27;s easy to pick up from where you left off.<p>Two big mistakes in the design of JavaScript that work against easy &quot;asynchronous programming&quot; are:<p>1) That &quot;this&quot; is not lexically bound in the local scope (technically it&#x27;s a magic &quot;keyword&quot; that&#x27;s dynamically bound by the interpreter), even though in most cases capturing &quot;this&quot; lexically is what you really mean to do.<p>To mitigate that problem, you have to do silly stuff like &quot;var self = this;&quot; to copy dynamically scoped &quot;this&quot; into lexically scoped &quot;self&quot;.<p>2) Each { block } doesn&#x27;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.<p>To mitigate that problem you have to wrap another function(){ ... }(); around the loop body to capture the values for each loop individually.<p>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.<p>But modern bleeding edge JavaScript now has &quot;=&gt;&quot; fat arrow functions that bind this lexically, and &quot;let&quot; that declares block scope variables. (But that&#x27;s not supported in all browser yet.)<p>Yay for progress! Worse may be better, but once you&#x27;ve wiped out the competition and taken over the world, there&#x27;s no reason to keep it worse on purpose.