21–30 of 115 posts
Am I the only one who is happy using normal callbacks? I think they are the best representation of the asynchronous flow.
Since async/await deal with promises, there's nothing stopping anyone from not awaiting a dependency at the top level so that some loading logic can be run.
In addition, since these are promises, there's nothing stopping us from awaiting multiple promises at once in parallel like so:
const [dependency1, dependency2] = await Promise.all([promise1, promise2]);
I don't even understand why top level await is necessary given HTTP 2 server push. The point is that import statements at the top can be statically analyzed so the web server can determine which dependencies to push down to you with your request. That's not quite here yet, but by the time this proposal is ready I'm sure it will be.
I guess if you need to use runtime evaluation for something to determine you're dependencies it makes sense but I've found that's rarely the case.
Earlier quoted context omitted.
Well, I was happy using normal callbacks, but then promises made me a bit happier and now I even happier with async/await. You can definitely write clean code with only callbacks, but one has to be pretty careful if there are many nested asynchronous actions. Promises and await make that code very much clearer.
Also, if you're trying to do something after multiple async operations, you've got to manually count your callbacks. (As opposed to using Promise.all)
I've seen examples of it in JavaScript and the author is always like, "Look at what you normally have to write and now look at what you COULD write with async and await!"
And it's like the same goddamn code with a few minor differences.
If they axed the whole proposal, I could get through this holiday season without even being depressed a little bit.
> Even assuming all goes well, you've prevented yourself from doing any other work, like rendering views that don't depend on that data. Is that right? `await` is non-blocking, no?
`await` allows the event loop/job queue to run while waiting. However, while using `import` declarations , your module will not run until all imports have completed; this means that your module will be suspended while the dependency awaits. If your app is shipped as a single bundle this means your entry point would be unable to run anything while dependencies are awaiting if you use `import` declarations. If your app…
> your entry point would be unable to run anything while dependencies are awaiting
is very different from the situation with synchronous I/O (in a single-threaded environment).
With sync I/O, not only is your entry point unable to do anything (which is what it chose to do, by using `import` instead of `import()`), your entire app is unable to do anything! So other entry points are also blocked.
Even worse, since sync I/O blocks the event loop, it prevents the user from interacting with your web page or Node app---e.g. scrolling, clicking links, pressing Ctrl+C to exit, and so on.
Earlier quoted context omitted.
Also, if you're trying to do something after multiple async operations, you've got to manually count your callbacks. (As opposed to using Promise.all)
No. You use flow management library. Just how you don't manually execute multiple promises with `Array.forEach` and same manual counting. Latter just happens to be in stdlib while former is userland.
Am I the only one who is happy using normal callbacks? I think they are the best representation of the asynchronous flow.
This is basically the same old argument against `await` itself: that it allows developers to write bad code that should be parallelized more (by using Promise.all etc.). It didn't stop await inside async functions, and it's not going to stop top-level await. (The argument also seems to be predicated on some fundamental misunderstandings, in that it thinks everything would have to be sequentialized. See my other repli…
> This is basically the same old argument against `await` itself: that it allows developers to write bad code
It magnifies the effect to a degree that isn't immediately obvious – hence footgun. Users are the ones who will suffer, therefore it's right that we exercise some restraint.
Earlier quoted context omitted.
No. You use flow management library. Just how you don't manually execute multiple promises with `Array.forEach` and same manual counting. Latter just happens to be in stdlib while former is userland.
Please give an example of a flow mgmt lib.
I'm not terribly familiar with this new proposal but I have used the regular async/await features quite extensively and can't really see a problem here. Since async/await deal with promises, there's nothing stopping anyone from not awaiting a dependency at the top level so that some loading logic can be run. In addition, since these are promises, there's nothing stopping us from awaiting multiple promises at once in…