I don't understand the current obsession - which started roughly 15 years ago - with threading, await/async patterns, etc. And I say this as someone who was QUITE fascinated by the topic (I was in the final stages of writing an article for MSDN Magazine on the topic in the 2006, 2007 time period!).

It. Has. It's. Place.

It's place is NOT where I see it being used most of the time!

Do you have 5,000 identical (other than the inputs), high-CPU use, hopefully low-RAM use, "no thread needs to touch other than to update the main thread with status" code to run? FANTASTIC. Multi-threading is great here!

Do we want to manage a zillion complex pieces of a whole, that need to coordinate closely with each other? Ummm... this code is going to be buggy and complicated, and in most cases I'm going to ask if the juice is worth the squeeze.

And then we get "multi-threading for the sake of multi-threading". Why is *so much* of JavaScript written with Promises? I have no idea. But I can tell you that as "someone who doesn't write much JS, but has to debug a fair amount of other people's JS", this pattern is much more difficult to debug, fix, etc. than straight code, and much/most of the time, it's just acting as straight code anyways.

So I scratch my head at so much of the code I see, and I ask "why was this written multi-threaded, where was the benefit, why go through this?" And I never get a satisfactory answer... it's usually "you old geezer, don't you know this is how we write code today?" and "look, I was handed this hammer, and by golly I'm going to try to hammer every fastener here!"

J.Ja