3 ms·

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 m

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.

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.