Two important things about JavaScript that enables easy "asynchronous programming" are:

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.

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...

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.

Ahh.... lovely, thank you. So what I'm referring to as "asynchronous javascript" is technically a colloquialism used to describe the event-driven callback-y nature of the code.

I'm not sure I'm still against referring to javascript as asynchronous or at least as having asynchronous methods for the purposes shorthand and quick communication.

Consider the code (or paste it into a chrome console)

     function _done(){ console.log(arguments) }
     var db = window.openDatabase("dbfoo", 1, "test db", 5e6)
     db.transaction(function(tx){
        tx.executeSql('CREATE TABLE t1(a, b PRIMARY KEY);', _done, _done)
     })
     console.log("i happen before the line above me")

Notice how the lines of code complete out of order. I think it's really useful to think of that as asynchronous code. It appears I'm using async as a term interchangeably with non-blocking... which may not be correct. So it may be the case that my nomenclature is off, but I'm sure I got that from somewhere. Perhaps a lot of people were referring to node as async in the early days, I'm re-watching this: https://www.youtube.com/watch?v=ztspvPYybIY now, but it doesn't look like Ryan Dahl uses the term async.

Anyways, looks like I'll have to train myself to use the right word for it. Thanks for pointing that out without making me feel dumb or being all insulting and internet-y. :) I really appreciate that.

EDIT: Hmmm... additionally, to be fair: it appears that some agree that it is OK to refer to parts of javascript as async http://stackoverflow.com/a/16524240/398055 so it might not be perfectly accurate, but it isn't wildly inaccurate either.