4 ms·

why would one stick with callbacks? i understand why people might skip promises... but async/await????

by mpfundstein 6y ago

austincheney 6y ago
Logically its all the same at execution time, but with callbacks the control flow is more clear to read for me.
Scarbutt 6y ago
For another perspective, I skip async/await and prefer promises ;)
- mpfundstein 6y ago
  i like promises too and was one of the most vocal supporters. but they are alien to a lot of people. at least that's what I experienced so far :( async/await just feels right at home for everyone
  - city41 6y ago
    The trouble with async/await is to use it properly you really need to understand promises. For example, many people are stumped why you can't await inside of Array#map. I've always felt it's a leaky abstraction and I personally prefer to just use promises most of the time. I do find async/await a great fit for say puppeteer tests where the entire test is a long run of blocking async calls.
    - Kaze404 6y ago
      > many people are stumped why you can't await inside of Array#map Isn't that solved with a simple google search? Async/await makes the function return promises, so if you use an async callback in Array#map you end up with an array of promises, which you can use with Promise#all. Seems rather simple to explain and grok.
      - Epskampie 6y ago
        Now you are just confirming that you need to understand promises to use async.
        Kaze404 6y ago
        I agree with that. What I'm saying is it's really not that hard of a subject to understand or teach. At least not enough to prevent me from using it entirely.
    - johnsonjo 6y ago
      I don’t know much about compiler internals, but this sounds like it could complicate a lot of things and not have as many guarantees that the compiler could assume (thus since JS interprets code it could slow down runtime performance). I don’t know though maybe someone more in the compiler space could answer.
forty 6y ago
We use callback style at work, with heavy use of async.auto ("async" the node_module). One of the greatest function that npm can get you :) I'm a scala person, so I naturally tend to like promise style (and async/await is a nice sugar) but my experience interviewing a lot is that people that were not exposed a lot to callback style don't understand what asynchronous means, which is a good enough reason IMO to keep callbacks :) the fact that the std lib is also full of them (we are using node 12, I don't know what is the current status, but for now most of the std lib is callback only for us) does not make me want to do the switch at all.
- emilsedgh 6y ago
  Hahaha that's smart way of filtering out bad candidates. Maybe during the interview process we should make sure the candidates fully understand the callback style and Javascript's async model. We also have a big project. we started during callback days, skipped promises (I never thought promises alone were an improvement over callbacks and async.auto). But as soon as async/await was in, we allowed them in the codebase. So now the codebase is a mess, with some functions being callback style and some others promises, stiched together we promisify functions. Im hoping in a 2-3 years time frame all our callback style functions will be eventually phased out during small refactors and rewrites. This migration plan is the only method i found that enables projects to move from A -> B without spending massive times rewriting the whole project and yet keeping up to date with technologies so they wouldn't need a rewrite every 10 years.
  - forty 6y ago
    > Maybe during the interview process we should make sure the candidates fully understand the callback style and Javascript's async model. I used to ask candidates to implement async.map and I used to be baffled that the majority of JS devs are unable to do it. There are those who would say "I'm not used to callbacks, I use promises". I would then allow them to use promises (no Promise.all allowed, that's what we are trying to implement ^^). I have never seen one of those "promise only candidate" manage to do the exercise. If you want to push it to the next level, ask them to implement async.mapLimit. You wouldn't believe how few people that are looking time professional JS devs, are actually able to do it properly (I actually used to ask that one, before realizing that it was too much to ask... )
BenoitEssiambre 6y ago
I love async/await but I really wish it wasn't built on promises. All you would have had to do is make it so when you use the await keyword, you don't pass the callback, the runtime passes it for you, pauses the function and resumes it when the callback is called (returning values and throwing errors as you would expect). I implemented this here: https://github.com/bessiambre/casync https://github.com/bessiambre/casync but it would be even better with language level support. Whenever I encounter JS beginners and they ask me about simple looping over asynchronous operations sequentially, I mention async/await, the discussion veers towards promises and then I have to mention the state machine and the caching layer for errors and return values, pending, fulfilled, rejected, settled states, reject/resolve callbacks and how it all fits together with 'then' chaining and 'dynamic replacement' by which point they just want to go back to Python or whatever. With a callback based async/await, I could just say: Here, with this keyword, the function will pause until the callback is called. Just put your function taking a callback in a normal loop and await it. It would be cleaner, more functional, more stateless and faster. The features of promises aren't even used with async/await. The point of promises, the caching layer and the state machine, is to be able to add the continuation later but with async/await, it is always just the next line in the function so it doesn't need to be added later. It's unnecessary performance penalty, complexity and statefulness on every asynchronous function call. I did try to propose this as a language feature here: https://es.discourse.group/t/callback-based-simplified-async-await/343/7 https://es.discourse.group/t/callback-based-simplified-async... It didn't get much traction an I was too busy to push it further.

why would one stick with callbacks? i understand why people might skip promises... but async/await????

austincheney 6y ago

Logically its all the same at execution time, but with callbacks the control flow is more clear to read for me.

Scarbutt 6y ago

For another perspective, I skip async/await and prefer promises ;)

mpfundstein 6y ago
i like promises too and was one of the most vocal supporters. but they are alien to a lot of people. at least that's what I experienced so far :( async/await just feels right at home for everyone
- city41 6y ago
  The trouble with async/await is to use it properly you really need to understand promises. For example, many people are stumped why you can't await inside of Array#map. I've always felt it's a leaky abstraction and I personally prefer to just use promises most of the time. I do find async/await a great fit for say puppeteer tests where the entire test is a long run of blocking async calls.
  - Kaze404 6y ago
    > many people are stumped why you can't await inside of Array#map Isn't that solved with a simple google search? Async/await makes the function return promises, so if you use an async callback in Array#map you end up with an array of promises, which you can use with Promise#all. Seems rather simple to explain and grok.
    - Epskampie 6y ago
      Now you are just confirming that you need to understand promises to use async.
      - Kaze404 6y ago
        I agree with that. What I'm saying is it's really not that hard of a subject to understand or teach. At least not enough to prevent me from using it entirely.
  - johnsonjo 6y ago
    I don’t know much about compiler internals, but this sounds like it could complicate a lot of things and not have as many guarantees that the compiler could assume (thus since JS interprets code it could slow down runtime performance). I don’t know though maybe someone more in the compiler space could answer.

forty 6y ago

We use callback style at work, with heavy use of async.auto ("async" the node_module). One of the greatest function that npm can get you :) I'm a scala person, so I naturally tend to like promise style (and async/await is a nice sugar) but my experience interviewing a lot is that people that were not exposed a lot to callback style don't understand what asynchronous means, which is a good enough reason IMO to keep callbacks :) the fact that the std lib is also full of them (we are using node 12, I don't know what is the current status, but for now most of the std lib is callback only for us) does not make me want to do the switch at all.

emilsedgh 6y ago
Hahaha that's smart way of filtering out bad candidates. Maybe during the interview process we should make sure the candidates fully understand the callback style and Javascript's async model. We also have a big project. we started during callback days, skipped promises (I never thought promises alone were an improvement over callbacks and async.auto). But as soon as async/await was in, we allowed them in the codebase. So now the codebase is a mess, with some functions being callback style and some others promises, stiched together we promisify functions. Im hoping in a 2-3 years time frame all our callback style functions will be eventually phased out during small refactors and rewrites. This migration plan is the only method i found that enables projects to move from A -> B without spending massive times rewriting the whole project and yet keeping up to date with technologies so they wouldn't need a rewrite every 10 years.
- forty 6y ago
  > Maybe during the interview process we should make sure the candidates fully understand the callback style and Javascript's async model. I used to ask candidates to implement async.map and I used to be baffled that the majority of JS devs are unable to do it. There are those who would say "I'm not used to callbacks, I use promises". I would then allow them to use promises (no Promise.all allowed, that's what we are trying to implement ^^). I have never seen one of those "promise only candidate" manage to do the exercise. If you want to push it to the next level, ask them to implement async.mapLimit. You wouldn't believe how few people that are looking time professional JS devs, are actually able to do it properly (I actually used to ask that one, before realizing that it was too much to ask... )

BenoitEssiambre 6y ago

I love async/await but I really wish it wasn't built on promises. All you would have had to do is make it so when you use the await keyword, you don't pass the callback, the runtime passes it for you, pauses the function and resumes it when the callback is called (returning values and throwing errors as you would expect). I implemented this here: https://github.com/bessiambre/casync https://github.com/bessiambre/casync but it would be even better with language level support. Whenever I encounter JS beginners and they ask me about simple looping over asynchronous operations sequentially, I mention async/await, the discussion veers towards promises and then I have to mention the state machine and the caching layer for errors and return values, pending, fulfilled, rejected, settled states, reject/resolve callbacks and how it all fits together with 'then' chaining and 'dynamic replacement' by which point they just want to go back to Python or whatever. With a callback based async/await, I could just say: Here, with this keyword, the function will pause until the callback is called. Just put your function taking a callback in a normal loop and await it. It would be cleaner, more functional, more stateless and faster. The features of promises aren't even used with async/await. The point of promises, the caching layer and the state machine, is to be able to add the continuation later but with async/await, it is always just the next line in the function so it doesn't need to be added later. It's unnecessary performance penalty, complexity and statefulness on every asynchronous function call. I did try to propose this as a language feature here: https://es.discourse.group/t/callback-based-simplified-async-await/343/7 https://es.discourse.group/t/callback-based-simplified-async... It didn't get much traction an I was too busy to push it further.