[gruseom]

You're right that "scope" isn't the right word to use there, but I still can't think of a better one.

Trying to accommodate the complexity you describe ahead of time could well be its own mistake. One thing I've learned in the trenches is to wait for most things to prove to be a problem before adding complexity to address them. I believe you that there are cases like you and the OP describe, where "all sync or all async" is a good invariant to have. But I don't believe it's a general rule, the alternative to which is doing it wrong (or even the devil, as in the OP).

Another thing one learns in the trenches is that almost all general rules about software are bogus and end up distorting one's thinking. It's better to choose invariants on a system-by-system basis.

[aegiso]

Isaacs is writing from a node context, where apps are basically collections of third party modules glued together. In that kind of world, it's expected that things will work a certain way and not deviate, or your code ends up being crusted up by the glue and exception handling.

The issue with "wait until it's a problem" in node is that dependency updates can and will ruin your assumptions if you haven't been diligent about doing things the standard nodeish way. For better or worse, the node community pushes this pretty hard.

So the way I see it, this isn't about blind application of general rules. It's about having a standard API in your framework. And I firmly believe that the reason npm ecosystem works so well is because of people following these standards.

Though I do agree izs appears to be overgeneralizing his conclusions.