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...
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)
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();
})();
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).
Why async AND Task<>? Surely one is enough.