I don't like it either (it's just syntactically annoying), but I am pretty sure it's there just for historical reasons: https://developer.okta.com/blog/2019/01/

I don't like it either (it's just syntactically annoying), but I am pretty sure it's there just for historical reasons: https://developer.okta.com/blog/2019/01/16/history-and-future-of-async-javascript https://developer.okta.com/blog/2019/01/16/history-and-futur... It's at least cleaner than a bunch of chained .then()s or nested callbacks, which is what we had to do in the old days. If you don't want to use async/await, you can still do it the old-fashioned ways. But it's not really that difficult to just wrap whatever you're doing in an async call, is it? e.g. (async () => { await someAsyncThing(); await Promise.all(aFewAsyncThings[]); await someOtherThing(); })(); Will cause all of those to run in sequence as synchronous operations one after another. Promise.all() can help with concurrent async things, or you can use a queuing library like p-throttle/p-limit if there are rate limits to observe. Yeah, it's a bit of syntactic complexity, but once you get the hang of it, they're not so bad and let you more cleanly think about which operations are synchronous & blocking and which can be async in the background (important for both performance and UX).