4 ms·

> JavaScript Promises Discussion: Make Them Monadic? No, just totally ditch them! I can't help to hate Promises. Sometimes I have to work on a code base that

> JavaScript Promises Discussion: Make Them Monadic? No, just totally ditch them! I can't help to hate Promises. Sometimes I have to work on a code base that is completely baked with them, it's just a nightmare. With the stupid async await implementation things haven't got any better.. Now they expect me to write async calls in a try-catch block!?! With JS I prefer to use simple callbacks until they come up with a proper async await without try-catch and Promises bullshit. Callback hell happens not because of the callback principle itself. It exists because it's too easy to keep nesting functions. Most devs simply don't know how, or are too lazy, to apply good patterns for using callbacks.

tomc1985 9y ago
This. Every time I try and get up to speed on those things it's like, "wtf? this is actually better?"
jey 9y ago
> Now they expect me to write async calls in a try-catch block!?! What do you mean? In my experience, the use of async/await leads to much cleaner code for I/O driven tasks like querying APIs and databases. Yes, I do have a try/catch at the top of the callstack to catch and log unexpected errors.
- vorpalhex 9y ago
  async/await worries me, not for abstract language reasons but because it hides complexity in a way not friendly for junior engineers. I imagine a lot of code that should be thought out and made parallel being forced into a synchronous flow. Note that promises aren't a ton better in this regard, and come with a ton of confusion themselves. In short, async is hard.
  - jey 9y ago
    Promise.all() does a pretty good job of parallelizing tasks while maintaining readability.
orf 9y ago
Having seen several codebases go from using arbitrary callbacks (two? One with an error arg? Why not both?) To promises/asynchronous/await it's hard to see your point. The code is cleaner, there is no callback hell with await, in fact no callbacks at all. And yes, you do need to use a try/catch block where appropriate. Stop trying to emulate a try/catch with ridiculous nested callback passing that inevitably leads to the function not being called and data being lost. Just stop.
yladiz 9y ago
I'm not sure how it works in all languages, but in Python you have to deal with errors in a try/except block. In general the way you handle errors that happen on "blocking" async calls is by wrapping in a try-catch style syntax and handle the error. How would you handle the error otherwise? You can handle asynchronous code in JS in four ways: callbacks, Promises, generators, and async/await. In the former two, errors are dealt with in a non try-catch way, to the programmer, because either you pass the error as the first callback parameter, or the VM handles error passing for you and you deal with it in a catch block. The latter two you must wrap code that may fail in a try-catch block (or just not handle the exception). You can stick with callbacks, but it's generally easier to read well written Promises, and in a lot of cases async/await make it even clearer. The only time that it can be confusing or difficult is if you want to do multiple await calls simultaneously.
rhinoceraptor 9y ago
Not to mention promises swallow programming errors that should fail loudly (TypeErrors, ReferenceErrors, etc), and treat them the same as you would treat an HTTP 500 error.
dboreham 9y ago
I think you'll find that the proper solution to this problem is : threads. (or actors, goroutines, CSP if you want to call them that instead). Promises and callbacks are something you'd do if you have an execution environment lacking threads (which is true of Javascript).
Lazare 9y ago
I have a number of criticisms of Promises, but I think your point is utterly wrong.

tomc1985 9y ago

This. Every time I try and get up to speed on those things it's like, "wtf? this is actually better?"

jey 9y ago

> Now they expect me to write async calls in a try-catch block!?! What do you mean? In my experience, the use of async/await leads to much cleaner code for I/O driven tasks like querying APIs and databases. Yes, I do have a try/catch at the top of the callstack to catch and log unexpected errors.

vorpalhex 9y ago
async/await worries me, not for abstract language reasons but because it hides complexity in a way not friendly for junior engineers. I imagine a lot of code that should be thought out and made parallel being forced into a synchronous flow. Note that promises aren't a ton better in this regard, and come with a ton of confusion themselves. In short, async is hard.
- jey 9y ago
  Promise.all() does a pretty good job of parallelizing tasks while maintaining readability.

orf 9y ago

Having seen several codebases go from using arbitrary callbacks (two? One with an error arg? Why not both?) To promises/asynchronous/await it's hard to see your point. The code is cleaner, there is no callback hell with await, in fact no callbacks at all. And yes, you do need to use a try/catch block where appropriate. Stop trying to emulate a try/catch with ridiculous nested callback passing that inevitably leads to the function not being called and data being lost. Just stop.

yladiz 9y ago

I'm not sure how it works in all languages, but in Python you have to deal with errors in a try/except block. In general the way you handle errors that happen on "blocking" async calls is by wrapping in a try-catch style syntax and handle the error. How would you handle the error otherwise? You can handle asynchronous code in JS in four ways: callbacks, Promises, generators, and async/await. In the former two, errors are dealt with in a non try-catch way, to the programmer, because either you pass the error as the first callback parameter, or the VM handles error passing for you and you deal with it in a catch block. The latter two you must wrap code that may fail in a try-catch block (or just not handle the exception). You can stick with callbacks, but it's generally easier to read well written Promises, and in a lot of cases async/await make it even clearer. The only time that it can be confusing or difficult is if you want to do multiple await calls simultaneously.

rhinoceraptor 9y ago

Not to mention promises swallow programming errors that should fail loudly (TypeErrors, ReferenceErrors, etc), and treat them the same as you would treat an HTTP 500 error.

dboreham 9y ago

I think you'll find that the proper solution to this problem is : threads. (or actors, goroutines, CSP if you want to call them that instead). Promises and callbacks are something you'd do if you have an execution environment lacking threads (which is true of Javascript).

Lazare 9y ago

I have a number of criticisms of Promises, but I think your point is utterly wrong.