Is this part of the standard?
Did you read the commit? The spec material was linked: https://tc39.es/proposal-top-level-await/#sec-execute-async-...
It's a Stage 3 proposal https://github.com/tc39/proposal-top-level-await
V8 adds support for top-level await
11–20 of 310 posts
Re: V8 adds support for top-level await
#12Awesome! How long before this shows up in canary?
Re: V8 adds support for top-level await
#13This is huge! Finally no more need to use IIFE's for top level awaits
Though it goes even beyond that.
It not only works for the main entrypoint module, but all other modules as well.
Though I can say I've ever encountered a reason to have that....
Re: V8 adds support for top-level await
#14Re: V8 adds support for top-level await
#15Is this part of the standard?
It's a stage 3 proposal[1], which according to the TC39 process[2] means "the solution is complete and no further work is possible without implementation experience, significant usage and external feedback."
In other words, it's all but standardized. Barring significant blockers coming from actual implementation experience this will most likely be ratified.
Re: V8 adds support for top-level await
#16Earlier quoted context omitted.
What is an IIFE?
Immediately invoked function expression - aka an anonymous function that executes as it is interpreted. (function() { console.log('test'); })(); In old versions of JavaScript, variables had to be scoped to the nearest function (rather than the nearest block) so IIFE where often used for namespacing: var $ = (function() { this.version = '1.2.3'; })(); $.version; // 1.2.3 This worked because the function would be immed…
Hate to be a wet blanket, but that second code sample won't work. The function doesn't return anything so $ === undefined. Even if it did, this in that context is bound to the global object, so is the same as setting a variable without var or let.
A proper example of IIFE for lexical scoping would be something like this:
var numbers = "";
(function(){
for (var i=0; iYour code snippet would kind of work as expected if used as a constructor. As in:
var $ = function() { this.version = '1.2.3'; };
var obj = new $;
console.log(obj.version); //1.2.3
Ah...brings me back to my SO days...
Re: V8 adds support for top-level await
#17This is huge! Finally no more need to use IIFE's for top level awaits
It's nice, I guess, but huge? Instead of: async function main() { // code } main().catch(console.error); I'll be maybe writing: try { // code } catch (ex) { console.error(ex); } Hrm?
One thing that has bitten me is when you are using vm.run* and friends, it's impossible to get a result of it if you need to use async calls. Hopefully this solves that case.
There is also the original use case that the original proposal of needing to do async calls when during module loading.
Re: V8 adds support for top-level await
#18Does rust async support this?
Re: V8 adds support for top-level await
#19All this async code without decent locking primitives is leading to a rabbit hole of race conditions...
It doesn't matter that it's all single threaded if all your function calls may or may not block and run a bunch of other code in the meantime, mutating all kinds of state.
I feel like JavaScript developers of the 2020's are going to relearn the same things the C programmers of the 1990's learn, just a few levels of abstraction higher.
Re: V8 adds support for top-level await
#20Is this part of the standard?
Did you read the commit? The spec material was linked: https://tc39.es/proposal-top-level-await/#sec-execute-async-... It's a Stage 3 proposal https://github.com/tc39/proposal-top-level-await
I did. It looked like a diff, and since I don't have much interest in the internals of v8 I closed the tab.
Welcome to the internet!