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

51–60 of 115 posts

Re: Top-level await in JavaScript is a footgun

#51

Post by MaulingMonkey »

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…

I'm a fan of async/await in C#, but never use them. I've been deep into the bowels of callback hell and it's lame. Debugging other people's asynchronous state wrangling machines is also lame.

But I just don't write enough asynchronous code to actually benefit that much from async/await, and not all asynchronous patterns map nicely to the hierarchical nature of call graphs for me to take advantage of async/await all that sanely, as I found out from a few attempts to force the issue. And how do I add good debug visualizers to display tasks in flight? How do I serialize out long running async tasks? How do I modify things without breaking that serialization?

Re: Top-level await in JavaScript is a footgun

#52

Post by domenicd »

mstade wrote: post #49

Also, not to forget, `async import` would hide any potential syntax errors or errors in loading, since promises silence exceptions unless explicitly handled. Unless, of course, there's a special exception (no pun intended) to how promises work for imports.

This is false in every modern browser and environment.

Re: Top-level await in JavaScript is a footgun

#53

Post by domenicd »

gavinpc wrote: post #50
domenicd wrote: post #17

Earlier quoted context omitted.

That's false. Module loading and execution are separate stages. The dependent modules would load before this await is ever reached.

Wait... so the OP's premise is completely wrong? Doesn't the body of a module have to complete before dependent modules will execute their bodies? In other words, if you put for (let i = 0; i in the body of a module, wouldn't that block dependent modules for the duration of the loop? Would top-level await be different? edit The premise, as I understand it, is that the module itself is treated as the "currently-execut…

It would block dependent module execution, but not dependent module fetching, which is the actual expensive part.

Re: Top-level await in JavaScript is a footgun

#54

Post by domenicd »

rich_harris wrote: post #28
domenicd wrote: post #20

This is basically the same old argument against `await` itself: that it allows developers to write bad code that should be parallelized more (by using Promise.all etc.). 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 repli…

Thanks for clarifying the point re module evaluation not being sequential – that would seem to break some fundamental guarantees about execution order, but I guess that's a separate discussion. The point stands that your entry point has to wait until each of its dependencies and each of their dependencies (&c) have finished before your app can start, and it unavoidably slows down module loading. > This is basically t…

> The point stands that your entry point has to wait until each of its dependencies and each of their dependencies (&c) have finished before your app can start, and it unavoidably slows down module loading.

That's true regardless of whether you use top-level await or not.

Re: Top-level await in JavaScript is a footgun

#55

Post by domenicd »

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.), and would of course make sense for JS as well.

Re: Top-level await in JavaScript is a footgun

#56

Post by rapala »

ohitsdom wrote: post #39
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…

I find async/await in C# to be super useful, and fairly addictive once you start using it. Say you want to do three independent things in a function. How would you run them in parallel without async? Delegates, background workers, or threads? With async, this is simply done with Task.WhenAll().

Well, the runtime then runs the Tasks in a thread pool, so using Task.WhenAll is just a one more item to the list of options in that sense. It is a nice abstraction though.

Re: Top-level await in JavaScript is a footgun

#57

Post by thomasfoster96 »

rich_harris wrote: post #46
thomasfoster96 wrote: post #37

Earlier quoted context omitted.

> 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?

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?

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.

Re: Top-level await in JavaScript is a footgun

#58

Post by mstade »

domenicd wrote: post #52
mstade wrote: post #49

Also, not to forget, `async import` would hide any potential syntax errors or errors in loading, since promises silence exceptions unless explicitly handled. Unless, of course, there's a special exception (no pun intended) to how promises work for imports.

This is false in every modern browser and environment.

Really? They break if an exception happens on the await line? What happens if there's a `unhandledrejection` handler set?

Re: Top-level await in JavaScript is a footgun

#59

Post by thomasfoster96 »

dangoor wrote: post #47
thomasfoster96 wrote: post #35

Earlier quoted context omitted.

True, but I interpreted the OP as criticising any execution of code on module load (other than declaring exports). Unless loading a file is a bottleneck, which I doubt.

> Unless loading a file is a bottleneck, which I doubt. Loading a file is a bottleneck in the browser, right?

Right, but I don't see how top level await makes the current situation any worse. Web developers already have to think about the order of script loading and execution.

Re: Top-level await in JavaScript is a footgun

#60

Post by xg15 »

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());
Look ma, I stalled the page load with no synchronous XHR!
Post reply on HN