Not disagreeing, but as a long time JavaScripter it is remarkable to me that no matter how delightful or expressive or ergonomic the language tries to become, the same old criticisms manage to evolve with it (this may not be unique to JS).

[Edit] JS has long been criticized (fairly or not) for offering clunky "concurrency" strategies. If you must down vote, please have the decency to offer a counter perspective.

As someone who has been around for a long time and manages teams using many different languages (C,C++,C#,Java,Python,JavaScript) my JavaScript/Web teams are the most problematic in terms of cost/performance/gating bugs/upgrades/multi-platform support. The JavaScript critiques that you see are just an expression of the time and resources being wasted.

Where in the stack did you spend your time before you became a manager?

If you have callbacks, you end up with hard to read and debug code.

If you have transparent async, then:

Then how do you know what blocks and what doesn't ? What's asynchronous and what's going to trigger a switch ? What's a disguised callback and what's the next line ?

What's the solution then ?

Why would you need to know, except in some special cases? If you're using async/await, your next line is not executing anyway until the result comes, blocking or not.

Because otherwise you block the even loop or mismatch life cycle. Espacially reading an unfamiliar code base.

embrace higher-order functions. Use named functions and closures!

example code:

  var anchors = document.getElementsByTagName(“a”);
  for(var i=0,len=anchors.length; i<len; i++){
    alertClickAnchor(i); // Named function
  }

  function alertClickAnchor(i) { // Closure
    anchors[i].onclick = function() {
      alert(i);
    }
  }

This makes anything but basic life cycles very hard to read.

You can look at each function at a time and only have to understand what that function does. No more nesting.

What's wrong with that?