I'm still using .then().catch() instead of the async await.
So, first of all, Fuck you for calling it a STANDARD now. its nowhere near to be called standard. You wanna get some data from an API? Wanna call it using axios or fetch? What if the server is down? what if there's an error that you don't even know existed? Where do I get that kinda error in async await? try-catch? no thanks :| I'm good -_-

No one said you can't use promise methods in async functions. Go wild.

For example I gave some other .catch another function I wrote used in a different-but same purpose- .catch so +1 for readibility and re-using.

Defo better than try{}catch(e){handle(e);}

It's okay it's okay👾

try-catch is good though. Shut the fuck up, kindly.

Just fyi... Async await is nothing but a syntetic sugar that wraps a promise and allows different type of syntax.. the kind people can easily read, so there's no "missing" functionality when switching..

But I feel like all this anger is really about something else, all good there? 🙃

@lambda123 i hated js, until async-await was added and it finally started looking like a normal programming lang. So it's not bad now. With TS its looking even more like typical typed language

@vortex "the type of syntax people can easily read", and especially *miss*read. I fixed so many obscure async/await issues in production code others just looked past. Async code should look like async code.

It is a fine syntax for the simplest of cases (a single async op, or a few sequential ones), but it comes nowhere near the flexibility of Promise for handling parallel ops (.all/ .some), requires a stupid keyword that breaks at top-level in all but the latest Node versions and it is confusing as fuck in loops and array methods. A chain of reusable thenables is way more readable and succinct than try/catch blocks.

async/await was added to JS to make it look familiar to C#, Python etc. A mistake for a lang whose "functions are first-class citizens" imo, just like the lie that is the class keyword and the obscene politically motivated absurdity that custom elements are forced to use a "class extends".

Sorry, I felt like ranting

@vortex Thanks for your concern but the anger is really about this async-await thingie. I don't like to write boilerplates for simple tasks and it feels like, this async await is just increasing the amount of boilerplates without providing any proper solution. Would've been nice if the async await returned object from fetch or axios had both response and error, but it only gives the response, letting the error unhandled :/

I hope, I'm right. If not, pardon my ignorance...

@Xoka which makes sense, because the whole "return response and error to callback" in JS was a big clusterfuck anyways. Errors are meant to be thrown and not reduced to just another parameter that fucks up everything when nit explicitly handled.
Also:
await Promise.all(foo.map(fnThatReturnsPromise))
Is short, readable and can be used with try catch in a way that mostly makes sense.

Yes a .then makes sense here and there but dismissing await as a whole? It's the first time asynchronous stuff in JS doesn't look like someone shat in my editor.