I can't speak for Crockford obviously, but my guess is that all these extra features come at the cost of making the language "bigger". I think part of the reason people liked JS in the early days was (at least if you avoided the attempt at OOP) how simple it was. You basically only had a few core types that were flexible enough to do what you needed, you worked with simple functions that worked on those core types, and you built simple abstractions on top of that.

Obviously this can be a blessing or a curse depending on who's writing the code; it's not terribly hard to write yourself a spaghetti mess of chaos in JS. Callbacks lead to a mess of nested lambdas, promises are better but still a bit clunky, and trying to work within the "few core types" led to the famous "wat" video [1], so these things come in tradeoffs.

Still, I see where Crockford is coming from (at least if I understand his point correctly). My interview language of choice is JavaScript, and I rarely use anything introduced from 2015 or later (except the shorthand function syntax). I like that the core language has basically no bureaucracy, and you can focus on just writing code.

[1] https://www.destroyallsoftware.com/talks/wat

> Who wants endless nested promise chains?

One of the things Promises solves is nesting. If you're nesting them, you're doing it wrong.

(I don't mean "never nest them"... but if you find you're nesting them, see if you can refactor to "all()" them or similar)

You "should" never nest them, if you create a new Promise inside a .then() callback, immediately return it and move to a new .then() callback in the chain. Promises were built to flatten.

The hard part, of course, is threading complex flows of variables through your .then() callbacks where later Promise calls need a previous variable or three, and that's when a lot of people give up and just resort to deeper nesting. That's what async/await does the best at solving: capturing variables automatically in a simple state machine written like classic imperative code versus manually trying to thread state through callback closures and complex return types.

> Who wants endless nested promise chains?

Believe it or not, you can actually structure things so it's "flat" looking without async/await (or even without Promises for that matter, but Promises solve other problems too).

Just because someone argues against something like async/await, doesn't mean they want the thing async/await is supposed to address.