6 ms·
I'll give you 2 examples and tell me which is more readable: console.log('start') doA() .then(() => { doB() .then(() => { doC()
by Raed667 5y ago
I'll give you 2 examples and tell me which is more readable:
console.log('start')
doA()
.then(() => {
doB()
.then(() => {
doC()
.then(() => {
console.log('finish')
})
})
})
.catch((error) => {
console.log(error)
})
Or
console.log('start')
try {
await doA()
await doB()
await doC()
console.log('finish')
} catch (error) {
console.log(error)
}
- leipert 5y agoNo need to nest promises: console.log('start') doA() .then(() => doB()) .then(() => doC()) .then(() => console.log('finish')) .catch((error) => { console.log(error) })
- Raed667 5y agoi was being a bit facetious. "Real-life" code is usually more complex and nesting is needed when you have conditional logic (call doC or doD depending on the return value of the previous call etc..)
- BeefWellington 5y agoIs this not less typing and as clear? console.log('start') doA() .then(doB) .then(doC) .then(() => console.log('finish')) .catch((error) => { console.log(error) })
- mdaniel 5y agoIt's been my experience that doing it that way can fiddle with the `this` value of those B and C functions, although I do in general agree there's usually no need for the outer wrapping arrow function if the interior one doesn't care about `this` I believe your .catch can similarly be `.catch(console.log)` for the same reason
- trog 5y agoHere's a lazy third option: console.log('start') try { doA() doB() doC() console.log('finish') } catch (error) { console.log(error) } It seems to me async/await is a desperate attempt to try to make JavaScript less painful to deal with because of its asynchronous execution nature. I am not a JS expert and have not had many opportunities to work with it extensively, but I confess I have always struggled with this when dealing with JS; I have often wondered if the (alleged?) performance gains from executing JavaScript like this outweighs [what I have always perceived as] the significant extra verbosity and complexity required to manage simply executing things in order.
- yoz-y 5y agoI don't understand your example, if would only work if your doA,B,C functions were synchronous, which completely changes the paradigm and use case. It's simpler yes, but very different. (simple example: if that function were to be run when you click on a button, now you have a frozen UI.)
- trog 5y agoYep. I am just wondering if the paradigm of JS being asynchronous is just not worth the added effort in code complexity and all the workarounds that have had to be added in over the years to try to make it manageable. I personally find it a chore to work in JS compared to other languages that work the opposite way - everything is synchronous and things become a chore when you want to deal with async stuff. Again I have limited JS experience and have never enjoyed working with it (I just am not interested in front end stuff) so I'm sure it's stuff people get used to.
- noahtallen 5y agoCould you clarify what the paradigm of JS being asynchronous means? Usually, async calls are actually “async” in that you’re doing a network request or something actually asynchronous. The reason they have to be async is that you cannot just block all execution or else other things can’t happen while the network request is happening. Which means your entire application grinds to a halt. Other languages solve this in a similar way IMO, with async/await and actual threads. JS doesn’t have threads, so you can’t fork a process to handle network stuff apart from UI. I personally think that async/await is a lot more straightforward to use than forming a process. Additionally, async/await allows you to wait when you need to. You don’t have to await a promise — you can just call it, and then it will work in the background. You’ll just not be able to respond when it finishes work. (Because you aren’t “wait”ing for it.) What are some other examples with easier async in other languages? I’m just confused what you’re trying to get at. Everything in JS is synchronous. You only have async when you have async. Which is a lot, because a lot of stuff in the web is async.
- bryanrasmussen 5y agoThe complaint really is that if everything is sequential it is a fault in the language to make you explicitly say it every time, not that await is somehow worse than promises.
- andresgottlieb 5y agoIs everything sequential?
- bryanrasmussen 5y agoI didn't say it was, but in the example given basically everything was, hence the complaint the parent made was that in JS we are often writing a lot of await, or promises or what have you because we have a lot of things that need to be done sequentially in a particular part of the program, or, in a small script, where everything needs to be sequential.
- Raed667 5y agoIt's not really a JS issue here, just the ZS project decided to make `$` function async (for some good reason I'd think) but they could have gone the other way and make it synchronous by default. I don't believe this is a language specific choice, they could have done the same with C#
- _ZeD_ 5y agowell, almost?
- alpaca128 5y agoWhen I need to run something async in Bash I can just add a `&`. Done. The majority of my scripts are purely sequential, though, as the language lends itself well to sequential data processing/piping. I'm not seeing a benefit by wrapping almost every single command in 'await $`...`'. I get why you'd want to wrap Bash in a different language, especially when handling numbers. But I'd rather use something like Python than this verbose trickery.