Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Top-level await in JavaScript is a footgun

gist.github.com

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Top-level await in JavaScript is a footgun

#101

Post by xg15 »

bmeck wrote: post #64
xg15 wrote: post #60

Slighty off-topic, I'm surprised/amazed that top-level await is permitted at all. This looks like it would allow some interesting new patterns in web programming, though at the expense of wreaking havoc with traditional execution models. For example, await in event handlers: Is the event object still valid when doAnotherThing is called? Or await in script blocks: Welcome back, document.write(await fetchUsername()); L…

top level await is only possible in grammar w/ `await` as a reserved word. This is limited to Modules (type=module) and async functions. You can't put it in your click handler or random Script like the examples you gave.

I wasn't aware of that restriction. That makes sense. Thanks for the info.

Re: Top-level await in JavaScript is a footgun

#102

Post by rich_harris »

domenicd wrote: post #99
untog wrote: post #98

Earlier quoted context omitted.

Is it a good thing for your entire app to be held up by any component that needs to load data? I'm sceptical.

But your entire app wouldn't be held up! Only that subgraph.

So in the future, you'll have to split up your app into multiple entry points specifically to contain the effects of top-level await spilling out? Sounds like using explicitly async functions would be a far more understandable and maintainable approach.

Re: Top-level await in JavaScript is a footgun

#103

Post by bmeck »

egeozcan wrote: post #93
BinaryIdiot wrote: post #86

Earlier quoted context omitted.

In that script, yes. But in JavaScript you can have multiple scripts :)

> in JavaScript you can have multiple scripts You mean, you can embed multiple script elements in HTML? Yes. But allowing global await in ES spec means also enabling it in node.

or you could just do `import('a'); import('b');` to load `a` and `b` in parallel

Re: Top-level await in JavaScript is a footgun

#104

Post by Touche »

untog wrote: post #98
domenicd wrote: post #71

Earlier quoted context omitted.

Yes. Let's rephrase that first sentence. "Any module with a dependency on data that it needs to execute will have to wait for that data before it executes." That's a good thing.

Is it a good thing for your entire app to be held up by any component that needs to load data? I'm sceptical.

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

Re: Top-level await in JavaScript is a footgun

#105

Post by theefer »

domenicd wrote: post #94
Bartweiss wrote: post #91

Earlier quoted context omitted.

Can you elaborate at all? I'm familiar with the concept, but I didn't think that it was standard practice or heading that way for JS. I also have the impression that it comes with serious overhead of its own, making the "await considered harmful" performance claims valid even in that case. I don't mean that as an argument: if speculative fetches handle this issue I don't understand how, and I'd really like to know.

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 'x';`?

Re: Top-level await in JavaScript is a footgun

#106

Post by BinaryIdiot »

halis wrote: post #24

I was never a fan of async/await in C#, I just never found it that useful. 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 litt…

You're getting downvoted because I don't believe you made a compelling argument against await / async. I do, however, fall into a similar line of thinking. For instance the code given was already poorly constructed so yes await / async will make poorly conceptualized code look better. But await / async forced an asynchronous behavior into synchronous meanwhile many other aspects of your application will be using asynchronous in the traditional sense. So it essentially mixes the two. This makes the code less maintainable, in my experience, because now you have code that haves the same but is structured in two very, very different ways that look like the traditional, blocking way of structuring code.

Due to this mixing I've seen many mistakes occur using await / async.

Yes because people screw up doesn't mean you don't include / create the feature. But at the same time I find the mixing of the two awkward and confusing at times.

I'm a huge fan of messaging patterns and async / await isn't really useful in a message based system so I don't have much of a dog in this fight.

Re: Top-level await in JavaScript is a footgun

#107

Post by domenicd »

Touche wrote: post #100
domenicd wrote: post #55

Another misconception here is the lack of understanding of engines' speculative loading capabilities. It's very easy for an engine to notice `await import('./foo.js')` or even `await fetch('./foo.json')` during the tokenization phase, and realize it might be a good idea to go fetch that file (and in the former case, all of its dependencies). This is already done for HTML's tokenization phase (with img, iframe, etc.),…

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 the bright idea to measure how much the average web page could be improved by doing speculative preloading for fetch, and then if the measurements are favorable and the technical tradeoffs are manageable, it happens.

Re: Top-level await in JavaScript is a footgun

#108

Post by robpalmer »

rich_harris wrote: post #102
domenicd wrote: post #99

Earlier quoted context omitted.

But your entire app wouldn't be held up! Only that subgraph.

So in the future, you'll have to split up your app into multiple entry points specifically to contain the effects of top-level await spilling out? Sounds like using explicitly async functions would be a far more understandable and maintainable approach.

So the argument is that the bad-effects of top-level await are viral. One bad apple in the app entry point's dependency graph stalls evaluation of the main entry point. And to mitigate this risk, you have to segregate out sub-graphs that you safely load via imperative import().

Doesn't the same risk apply if one of the modules in the graph declaratively imports a module hosted on a slow external CDN?

Re: Top-level await in JavaScript is a footgun

#109

Post by untog »

Touche wrote: post #104
untog wrote: post #98

Earlier quoted context omitted.

Is it a good thing for your entire app to be held up by any component that needs to load data? I'm sceptical.

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 be synchronous, and losing that certainty seems like a bad idea to me.

Re: Top-level await in JavaScript is a footgun

#110

Post by untog »

robpalmer wrote: post #108
rich_harris wrote: post #102

Earlier quoted context omitted.

So in the future, you'll have to split up your app into multiple entry points specifically to contain the effects of top-level await spilling out? Sounds like using explicitly async functions would be a far more understandable and maintainable approach.

So the argument is that the bad-effects of top-level await are viral. One bad apple in the app entry point's dependency graph stalls evaluation of the main entry point. And to mitigate this risk, you have to segregate out sub-graphs that you safely load via imperative import(). Doesn't the same risk apply if one of the modules in the graph declaratively imports a module hosted on a slow external CDN?

It does, yes. Using a slow, external CDN is a bad idea for exactly that reason.
Post reply on HN