Top-level await in JavaScript is a footgun • Hacker News Board

Re: Top-level await in JavaScript is a footgun

#111

Post by Touche » Thu, Sep 15, 2016, 1:13 AM UTC

untog wrote: post #109

Touche wrote: post #104

Earlier quoted context omitted.

So you're ok that your app waits on module dependencies, but data dependencies it should not?

But my app doesn't wait on module dependencies - the code is bundled. It does wait on code parsing time (which no, I don't consider ideal) but that's a far cry from waiting on an async data download operation. As far as I'm concerned, an explicit call to `ModuleB.loadData()` is far better than having it happen as part of module loading, without me necessarily being aware of it. Right now, module loading is assured to…

If you're going to perpetually use scripts then this conversation doesn't apply to your. Your script bundles will continue to work as they already do.

Re: Top-level await in JavaScript is a footgun

#112

Post by Touche » Thu, Sep 15, 2016, 1:13 AM UTC

domenicd wrote: post #107

Touche wrote: post #100

Earlier quoted context omitted.

I understand why `await import('./foo.js')` works here, as import() is not a normal function. But in the case of `await fetch('./foo.json')`, fetch is a global. What happens if my code overwrites window.fetch and redirects ./foo.json to ./bar.json? Won't the engine try to fetch foo.json (which might not exist) when it should wait for the code to execute?

Similarly to the ` ` example above, it's a tradeoff. A speculative fetch is just that: speculative. It might not always be correct, but on balance, it's likely to improve the user's experience. I think it's pretty unlikely we'd see this kind of speculative preloading for fetch though, at least initially. More likely, it's done for imports, and then some number of months or years down the line some engineer or PM has…

Thanks, I wasn't aware that it would accept misses like this; I assumed that 404s would be avoided. Glad to learn something new, thanks!

Re: Top-level await in JavaScript is a footgun

#113

Post by tkxxx7 » Thu, Sep 15, 2016, 4:09 PM UTC

euroclydon wrote: post #26

elmigranto wrote: post #23

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 really enjoy this one - https://github.com/bigeasy/cadence

Re: Top-level await in JavaScript is a footgun

#114

Post by shados » Fri, Sep 16, 2016, 2:18 PM UTC

egeozcan wrote: post #82

shados wrote: post #65

Earlier quoted context omitted.

And then as you use promise based code more and more (including with async/await), you eventually come to realize that while it looked good at first, its deeply, deeply flawed, and is at best a stepping stone to Observables :)

An observable is semantically very different to a promise, even if it can be thought as a promise with subsequent success calls. Here is the proposal: https://github.com/tc39/proposal-observable

Your point being?

The semantic is different, but everything a promise can do, an observable can do (with roughly the same amount of code), but the other way around isn't true.

Observables are just better in basically every ways. Real world implementations also have proper error handling and decent APIs to handle aborting -today-, while the TC39 is still jumping back and forth trying to figure out how to handle it in promises so that Fetch can stop being useless.

Re: Top-level await in JavaScript is a footgun

#115

Post by domenicd » Thu, Sep 22, 2016, 10:34 AM UTC

theefer wrote: post #105

domenicd wrote: post #94

Earlier quoted context omitted.

Speculative fetching is a time-honored technique in web browsers. During the tokenization phase of HTML, CSS, and even JavaScript, they speculatively start a fetch for a given URL, so that if the data needs to be evaluated later, it is ready to go without a network round-trip. (In HTML: script, link, img, video, etc. elements; in CSS: @import declarations; in script: certain common document.write(' In the context bei…

> `await import('./foo.js')` could kick off a speculative fetch for foo.js Interesting, and kind of makes sense. However: > Of course that doesn't help for dynamic cases like `` await import(`./language-packs/${navigator.language}.js`) ``. Isn't that the main, possibly only advantage of `await import(...)` though? For static import names, why write `const x = await import('x');` if you can simply write `import x from…

Because await import() can be used inside if statements or similar.