Who else is annoyed of "await" in JS?

> In other languages like python you don't have to.

I'm confused since "I don't have to do this in python" is probably the worst choice you could make to try and run away from this. Python does have async/await and the semantics are very similar (in fact they're more restrictive in some ways). You will get the same interpreter errors if you try to call async functions and awaits in a non-async function.

https://docs.python.org/3/library/asyncio.html

You're more likely upset that Promises in javascript are more common, but if you understood what the js interpreter is doing in an async event loop and the backing structures needed to make those calls you'd understand the need for the correct annotations.

If your gripe is with just needing await/async in general, you should know you don't actually ever need to use await/async. The .then chaining form is an alternate and equivalent way of handling promises.

Since, if you've read this far, you're probably saying to yourself "this is guy is dumb and doesn't really understand what I'm talking about". I'll give you a rope I'll claim you don't want and which solves the problem you think you have.

You'll be happy to learn you are not correct to say you need to use async await or .then. You can break out of the async nesting and just wrap whatever async call you can't get away from in a synchronous wrapper.

The answers (with much stronger warnings than I've given you) await you here

https://stackoverflow.com/questions/9121902/call-an-asynchro...

(assuming this is JavaScript): there's a difference between awaiting a promise, and just declaring a promise.

Sometimes you want to declare a few promises first, before running await Promise.all() - sometimes, you don't even care for the results of all of the promises, and just want the first result to complete (promise.race)

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-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).

I have this problem in C#.

Why async AND Task<>? Surely one is enough.

Watch some videos on how the JavaScript event loop works and what await does and it will make more sense.