3 ms·
await feels more magical than other language constructs because, at least to me, async constructs are much more complicated than synch ones (if/else, functions,
by sktrdie 10y ago
await feels more magical than other language constructs because, at least to me, async constructs are much more complicated than synch ones (if/else, functions, for, etc). A quite important dimension that this await/async syntax adds is time. Now the programmer is forced to think about time, even though the code is meant to read sequentially.
For instance what is `return await asynchronousOperation(val);` meant to return? You'd think that a return always returns something immediately - however when reading this code your mind has to process also the await keyword and think about the extra time dimension.
With a callback you have clearer separation of concerns - you know you're passing the behavior (the function) as an argument that will be executed at some other moment in time.
This async/await stuff seems like a fix for "ok JS code is becoming callback hell, how do we fix it?", rather than thinking about what async programming actually means and how we can reason about it more naturally - for instance I don't want to code async stuff and have it look like it's sync, because well, they're different concepts!
- coldtea 10y ago>for instance I don't want to code async stuff and have it look like it's sync, because well, they're different concepts! They shouldn't be though. In the ideal case, code should be able to function 100% whether it's a sync or async operation -- kind of how promises (and async with promises) works. The async-ness should could just be a deployment/configuration detail.