11–20 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.
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.
I know that the argument that "silly developers shouldn't be allowed to do silly things" is a valid one, but I don't see a convincing argument that top level await is worse than what developers are currently doing, which is use synchronous functions to do IO at the top level. If anything, top level async would be an improvement, as it would give developers no reason to do synchronous IO. Edit: Additionally, ES6 modul…
Am I the only one who is happy using normal callbacks? I think they are the best representation of the asynchronous flow.
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.
Am I the only one who is happy using normal callbacks? I think they are the best representation of the asynchronous flow.
I haven't yet switched over to await because of things like the issues described in this post - I don't mind async operations being a little clunky because it highlights where they're actually happening. Only using a simple keyword makes me worry that the flow control won't get as much attention. For me, Promises are a happy medium that allow you do to do simultaneous operations (mapping, Promise.all) a lot more easily than you can with callbacks, but more obtrusively than with await.
I know that the argument that "silly developers shouldn't be allowed to do silly things" is a valid one, but I don't see a convincing argument that top level await is worse than what developers are currently doing, which is use synchronous functions to do IO at the top level. If anything, top level async would be an improvement, as it would give developers no reason to do synchronous IO. Edit: Additionally, ES6 modul…
ES6 modules are declarative in the sense that the dependencies are statically analyzable.
Top-level async would make asynchronous IO no different from synchronous IO! It's the worst of both worlds.
> the dependencies are statically analyzable
Exactly – which means modules can be loaded concurrently, without having to execute the code. By contrast, imperative loading has to happen sequentially. I explored this aspect of it in a follow-up: https://gist.github.com/Rich-Harris/41e8ccc755ea232a5e7b88de...
Am I the only one who is happy using normal callbacks? I think they are the best representation of the asynchronous flow.
> 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?
It's not so much about blocking as it is about delaying the module waterfall. E.g. a module that did `await new Promise(_ => setTimeout(_, 5000))` at the top would prevent any of its dependents from being loaded for 5 seconds.
> 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?
An async function is non-blocking. await is blocking within the async function . Top-level await basically boils down to a proposal to wrap your entire app inside an async function.
Earlier quoted context omitted.
ES6 modules are declarative in the sense that the dependencies are statically analyzable.
> If anything, top level async would be an improvement, as it would give developers no reason to do synchronous IO. Top-level async would make asynchronous IO no different from synchronous IO! It's the worst of both worlds. > the dependencies are statically analyzable Exactly – which means modules can be loaded concurrently, without having to execute the code. By contrast, imperative loading has to happen sequentiall…
That's false. You could still do plenty of things while this asynchronous I/O is happening (including allowing the user to interact with the page, or load other modules in the background).
> By contrast, imperative loading has to happen sequentially.
Yes, but notably, declarative loads are not blocked on imperative loads.
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 replies throughout this thread.)