Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I Avoid Async/Await

uniqname.medium.com

Post reply on HN
Print view View original

231–240 of 242 posts

Re: I Avoid Async/Await

#231

Post by Aeolun »

albedoa wrote: post #179
Aeolun wrote: post #86

Earlier quoted context omitted.

const myfunc = () => new Promise(resolve => resolve()) Is there anyone that actually likes this structure? I find it really hard to reason about what a line like this does. What is the upper limit on double arrows in one line?

Your gripe is that there are two arrows on one line? The second is an argument to the promise constructor. You should be able to reason about this line easily.

I think I was unclear. Of course you can figure out what the line does. It’s just that you have to figure it out.

Re: I Avoid Async/Await

#232

Post by Aeolun »

eyelidlessness wrote: post #160
eurasiantiger wrote: post #125

Earlier quoted context omitted.

IIRC that doesn’t actually happen if a native Promise is returned.

It does, but only if you also add a redundant await. Which I still do, even in TypeScript, unless there’s a compelling performance reason not to. I disagree with the article overall, but I do agree that making asynchrony as explicit as possible is a good idea. Otherwise you end up with code like: async function foo(bar) { // ... } function nonObviousAsyncFn() { // ... return foo(quux); } Explicit return types would h…

This would still return a promise for both functions. My IDE at least is really obvious about what happens.

Re: I Avoid Async/Await

#233

Post by emilfihlman »

dimgl wrote: post #64
emilfihlman wrote: post #28

Promises are the most awful programming syntax I have ever come across. Await is sweet release from death as nowadays almost all apis are forced onto promises. Thank god xhr and websockets came before promises were mainstream, but for example webserial is absolutely horrible to use. Function callbacks are the best, though I wish JS would support function scheduling.

Who actually thinks like this? Callbacks were absolutely unmaintainable. Promises (and `async/await`) are really not that hard.

Unmaintainable?

Promises make the most horrible spaghetti code there is. It is hard to read, hard to maintain and hard to reason about.

Callbacks are super simple and clear, both as an api and how data is passed.

Re: I Avoid Async/Await

#234

Post by albedoa »

Aeolun wrote: post #231
albedoa wrote: post #179

Earlier quoted context omitted.

Your gripe is that there are two arrows on one line? The second is an argument to the promise constructor. You should be able to reason about this line easily.

I think I was unclear. Of course you can figure out what the line does. It’s just that you have to figure it out.

If the implication is not that the "double arrows" are tripping you up, then yes you were unclear.

Re: I Avoid Async/Await

#235

Post by eurasiantiger »

kabes wrote: post #220
adamauckland wrote: post #152

Earlier quoted context omitted.

It could, but depending on how you use it, you're changing scoping.

True. But these days it's rare to see a scope other than what you'd expect from the short hand version. Old school JS with plain prototypes and flexible 'this' scope is very powerful, but is too hard to understand and thus rare these days.

That’s one of the neat things about JS: even outside the prototypal inheritance chain, classes can be (partially) composed of generalized, reusable functions, a bit like traits. Just import a function and bind it in the constructor (call).

Re: I Avoid Async/Await

#236

Post by doliveira »

stareatgoats wrote: post #230
doliveira wrote: post #204

Earlier quoted context omitted.

> simple thenable object Wouldn't you simply be reinventing promises?

Actually no. A promise is a thenable oject, true, but a complex one. Simple thenable objects are in the simplest form objects that internally just holds an array of methods defined in each then() block. These methods then execute one after another at runtime. Any slightly experienced dev can probably create a library object or class like this in under 100 loc as a dropin replacement for most promises needs, and get a…

Yeah, up until you need some extra functionality and you fall into the Inner-Platform effect (https://en.m.wikipedia.org/wiki/Inner-platform_effect). Promises are a well-established and battle-tested standard, I'd be very weary of someone reimplementing them for no reason.

Re: I Avoid Async/Await

#237

Post by garyrob »

magnio wrote: post #168
garyrob wrote: post #149

Earlier quoted context omitted.

I'm a newbie with respect to JS and especially promises and async/await, but I need to learn. If you could point me to some resource that does a really good job of explaining all this, I'd appreciate it very much. I expect that I wouldn't be the only one. What's something you'd recommend to a junior developer so that they wouldn't be one of the "many devs", as you put it, who do the wrong thing?

Not the parent, but I recommend understanding the event loop first: here [0] is a very good talk. Then, read the chapter on promise on javascript.info [1], as it explains the problems Promise set out to solve (callback hell), then as usual the excellent MDN article [2]. [0] https://www.youtube.com/watch?v=8aGhZQkoFbQ [1] https://javascript.info/async [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guid...

Just watched that video. Thanks! Excellent resource. Moving on to your other links.

Re: I Avoid Async/Await

#238

Post by garyrob »

lmc wrote: post #163
garyrob wrote: post #149

Earlier quoted context omitted.

I'm a newbie with respect to JS and especially promises and async/await, but I need to learn. If you could point me to some resource that does a really good job of explaining all this, I'd appreciate it very much. I expect that I wouldn't be the only one. What's something you'd recommend to a junior developer so that they wouldn't be one of the "many devs", as you put it, who do the wrong thing?

This doesn't directly answer your question, but... something to watch out for is experienced developers can also struggle with promises and async code if they've spent most of their career working with sync code. And when we 'get' it, the difficulty of the journey is often understated. This stuff can be hard , so don't sweat it if it seems frustrating. (On the other hand, it may be easier if you don't have years of s…

Thanks for this feedback.

Re: I Avoid Async/Await

#239

Post by zorr »

robmccoll wrote: post #84

Everytime I use a language with async / await syntax, I find myself wishing that awaiting async functions was the default behavior and that I had to specify when I didn't want that behavior. So much boilerplate, so many times I've seen bugs that are the result of not being aware of a function being asynchronous or that the function was later made asynchronous. Most of the time you want seemingly synchronous behavior…

Kotlin coroutines do something like this. Any calls to a suspend function from inside another suspend function will be a suspension point and does not need additional syntax. And typically, if you are writing Kotlin using a JetBrains IDE the IDE will have a little indicator in the gutter to show all the suspend function calls.

To me personally it is much more readable with the gutter indicators instead of additional await keywords inside the actual code but it has a drawback: you need an IDE that supports it. When reviewing code on gitlab/github there won't be any indicator.

Re: I Avoid Async/Await

#240

Post by zkldi »

recursivedoubts wrote: post #216
zkldi wrote: post #178

Earlier quoted context omitted.

How would you allow running the fetches in fetch /some-url as json fetch /some-other-url as json do_stuff_with(result1, result2) in parallel?

hyperscript is focused on the common cases for light front end scripting, so right now there isn't syntax for doing operations in parallel. If I needed that I would kick out to javascript and use Promise.all() to return an expression that hyperscript could then sync on the wheelhouse for hyperscript is stuff like: on load wait 5s transition my opacity to 0 remove me where you don't have to do any async or callback st…

I don't get it then; your fix to promises being complicated is to remove the ability to perform asynchronous actions. That's cool for a small scripting language I guess, but absolutely impractical for anything serious.
Post reply on HN