4 ms·

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

by jameslk 10y ago

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 parallel like so: const [dependency1, dependency2] = await Promise.all([promise1, promise2]); All await does is schedule the resumption of the code following an await later on, so any JS not depending on this blocking dependency can continue to run. That is, await doesn't block the entire execution, unless the rest of the entire app code is sitting behind an await. 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.

rich_harris 10y ago
Agree that `await` by itself is useful, and your example shows the correct way to use it for concurrent activity. The problem with top-level await is that any modules depending on a module with a TLA cannot execute until it's done – the effects cascade and magnify throughout your app, rather than being confined to an explicitly async function.
- thomasfoster96 10y ago
  > The problem with top-level await is that any modules depending on a module with a TLA cannot execute until it's done – the effects cascade and magnify throughout your app, rather than being confined to an explicitly async function. Can't I already do this by putting a fs.readFileSync call or a synchronous AJAX call in my code?
  - rich_harris 10y ago
    The comparison to sync XHR is apt – put it this way, if you could go back in time and prevent synchronous XHR from being a thing, wouldn't you?
    - thomasfoster96 10y ago
      Yep, I probably would. However, the argument against allowing await in top level code doesn't make much sense if all of these bad side effects already exist.
      - untog 10y ago
        This would just increase the surface area of a bad side effect, though. Barely anyone uses sync XHR and the API is being phased out to the Fetch API - why would we encourage re-adding baggage like that?
    - domenicd 10y ago
      See elsewhere in this thread for why the comparison to sync XHR is very misleading.
- jameslk 10y ago
  It seems it would only cascade through the entire app if only the app was designed around dependencies being available first before other code is run. That is, if the app is designed badly. Again, I don't understand the point of the proposal in this context since nobody should be awaiting a long list of dependencies to load first. If you have 100 dependencies that means you have 100 HTTP requests, which is really a poor design decision. That's why we bundle up dependencies into fewer chunks first before sending them down to the client. Edit: I understand that this would become a sequential issue if one import leads to a request which leads to further imports which lead to more subsequent requests. My point is that unless the developer(s) really don't understand how async/await works, they wouldn't reasonably design an app like this.
  - rich_harris 10y ago
    > only the app was designed around dependencies being available first before other code is run I'm not sure I follow – isn't that the definition of 'dependency'? > If you have 100 dependencies that means you have 100 HTTP requests, which is really a poor design decision Agree – and it turns out that's still the case with HTTP2. But bundling doesn't solve the problem of await blocking your app, unfortunately.
    - jameslk 10y ago
      Some of the "other code" may not depend on the dependency. I think the word dependency may have been confusing in my statement. Await doesn't actually block the entire app (or JS thread) like synchronous code does. It schedules the code that follows after an await in the same file or in an async function to run later. You probably already understand this, but my point is that other code outside of this context is free to continue running.

by jameslk 10y ago

rich_harris 10y ago

Agree that `await` by itself is useful, and your example shows the correct way to use it for concurrent activity. The problem with top-level await is that any modules depending on a module with a TLA cannot execute until it's done – the effects cascade and magnify throughout your app, rather than being confined to an explicitly async function.

thomasfoster96 10y ago
> The problem with top-level await is that any modules depending on a module with a TLA cannot execute until it's done – the effects cascade and magnify throughout your app, rather than being confined to an explicitly async function. Can't I already do this by putting a fs.readFileSync call or a synchronous AJAX call in my code?
- rich_harris 10y ago
  The comparison to sync XHR is apt – put it this way, if you could go back in time and prevent synchronous XHR from being a thing, wouldn't you?
  - thomasfoster96 10y ago
    Yep, I probably would. However, the argument against allowing await in top level code doesn't make much sense if all of these bad side effects already exist.
    - untog 10y ago
      This would just increase the surface area of a bad side effect, though. Barely anyone uses sync XHR and the API is being phased out to the Fetch API - why would we encourage re-adding baggage like that?
  - domenicd 10y ago
    See elsewhere in this thread for why the comparison to sync XHR is very misleading.
jameslk 10y ago
It seems it would only cascade through the entire app if only the app was designed around dependencies being available first before other code is run. That is, if the app is designed badly. Again, I don't understand the point of the proposal in this context since nobody should be awaiting a long list of dependencies to load first. If you have 100 dependencies that means you have 100 HTTP requests, which is really a poor design decision. That's why we bundle up dependencies into fewer chunks first before sending them down to the client. Edit: I understand that this would become a sequential issue if one import leads to a request which leads to further imports which lead to more subsequent requests. My point is that unless the developer(s) really don't understand how async/await works, they wouldn't reasonably design an app like this.
- rich_harris 10y ago
  > only the app was designed around dependencies being available first before other code is run I'm not sure I follow – isn't that the definition of 'dependency'? > If you have 100 dependencies that means you have 100 HTTP requests, which is really a poor design decision Agree – and it turns out that's still the case with HTTP2. But bundling doesn't solve the problem of await blocking your app, unfortunately.
  - jameslk 10y ago
    Some of the "other code" may not depend on the dependency. I think the word dependency may have been confusing in my statement. Await doesn't actually block the entire app (or JS thread) like synchronous code does. It schedules the code that follows after an await in the same file or in an async function to run later. You probably already understand this, but my point is that other code outside of this context is free to continue running.