There are multiple approaches for handling asynchronous operations in Javascript. Some of the most common ways include Callback functions, Promises, and Async/Await.
Which one do you prefer to use and why?
There are multiple approaches for handling asynchronous operations in Javascript. Some of the most common ways include Callback functions, Promises, and Async/Await.
Which one do you prefer to use and why?
For further actions, you may consider blocking this person and/or reporting abuse
VAIBHAV RAI -
Preethi Puttegowda -
Plain -
Rose Michelle -
Top comments (11)
For me all of them have a different purpose. By default, if you want sequential code: Async/Await. More readable.
If you are in an event driven code (with a trigger that can be called several time), you have to use callbacks.
In some very specific cases, I use promises, for instance to have a queue of operation
I agree. Everything has it’s best use case and nothing is the best tool for everything.
I use promised more out of not being fully comfortable with async/await yet, even though async/await seems like the better tool for the job in a lot of cases. But I always hated callbacks, so anything else is better. 😄
async
-await
- but sometimes it just makes sense to use athen
with a traditionalPromise
.We should remember that
async
is nothing but a 'wrapper' or syntacic sugar for aPromise
- it's not wholly different thing.async
just makes our code a bit easier to read as it 'looks' 👀 synchronous. And, no callback is needed, mostly. 👍🏾Callbacks
are generally just for 'event based' UI stuff, such asaddEventListener
.Async/await is actually implemented based on Promise so the differences are mostly in how you code.
Promise
Promise sucks when we need variables across multiple
then
, yet this can be solved by an additional local variable:This
local
variable in Promise case serves like the local scope of the async case.Async/await
On the other hand, In async/await you need
try/catch
to handle exception, which induces possibly nested code segment if you have complicated logic to handle:The counterpart of
try/catch
in Promise is thecatch
function.which one?
I tend to still use Promise than async/await because:
about exception handling
While Promise still nests regarding complicated error-handling, it's also more "functional".
about local scope
While we need an extra
local
variable in Promise, codes and variables are segregated in their own scope insidethen
function call.This may be opinion-based but I think it's less error-prone since only variables with
local
prefix are accessible across all functions.And callback function?
Since
Promise.then(function() { })
is actually a callback pattern, we are using it all along. But will choose Promise if possible. :)I actually jumped from callbacks to async/await. Promises for some unknown reason just didnt capture the "full fix" to the problem for me. I had battled callbacks for a long time and I think smaller, cleaner functions ended up reducing the amount of callback hell I hit in a single implementation. I started to notice posts on various blogs discussing the endless .then world too.
In the end when async/await came along it felt like the most natural method to writing code, without the nesting and ultimately more readable.
Callbacks always leads to callback hell. If I start something and end up needing more than 3-4 asynchronous calls, I will always refactor to async/await if for some reason I start up with callbacks (it happens, particularly if I start from an example).
+1 — The code is cleaner and I won’t end in callback hell. Or have strangely nested Promises because I need values from various responses.
Async await when there are multiple async actions, but I don't mind using callbacks for simple stuff like running a function after 2 seconds seconds using useTimeout.
Well, Promises and Async/Await are basically the same, so I use both of them but I don't use callbacks because I don't like them.
RxJS, Async/Await, Promises, callback functions. This is my list of tools composed by preference priority.