TC39, ECMAScript, and the Future of JavaScript(ponyfoo.com)
ponyfoo.com
TC39, ECMAScript, and the Future of JavaScript
https://ponyfoo.com/articles/tc39-ecmascript-proposals-future-of-javascript
99 コメント
It's worth noting that proposals can move down as well. For example, I think there was lots of work done on atomics before it was ultimately scrapped. Heck, the global proposal doesn't look like it has moved in months due to a few web compatibility issues.
The shared memory and atomics proposal was approved as part of the ES2017 spec. https://github.com/tc39/ecmascript_sharedmem
Ah, it looks like you're correct. Apologies, I actually meant SIMD[0].
[0] https://github.com/tc39/ecmascript_simd
[0] https://github.com/tc39/ecmascript_simd
When will js have enough features? Maybe not there yet, but is there an endgame?
The language doesn't need too much more. Don't get me wrong, it's still not a great language but within the confines of what it is and backward compatibility, it doesn't need much more. The 'standard library' and browser apis though, have a long way to go.
The need for backwards compatibility is what is keeping JavaScript still not a great language. The number of wtfs and surprising behaviour is justified by needing to conform to what the language already did, and that is not a good thing.
I think the combination of introducing new features in a non-overlapping way with the ones they replace, and the use of linters to prevent you from using the old ones, is a pretty good way to improve the language without being affected by backwards compatibility.
Which wtfs bite you the most?
I can't remember being bitten lately, maybe I have a blind spot.
I can't remember being bitten lately, maybe I have a blind spot.
In a lot of the places where NaN is generated, I would prefer it if an error was thrown.
I think all JS NaNs are quiet NaNs when sometimes signaling NaNs should be supported/be preferable https://en.wikipedia.org/wiki/NaN#Signaling_NaN
They should do something like Python. Python 3 is loads better than Python 2. It removes legacy cruft at all levels cleaning it up completely. It even made Python 2.7 a backwards compatible language in which you can write code that with minimal modifications can be just moved to a Python 3 version. (Using modules like future)
Except upgrading to Python 3 on your application server is pretty trivial to do.
There are too many client vendors and devices for this to work. And even with the new features in ES2015, almost everyone actually using them is still using Babel to support older browsers.
There are too many client vendors and devices for this to work. And even with the new features in ES2015, almost everyone actually using them is still using Babel to support older browsers.
I think it could work. Are there any reason for this not to be implemented?
No BDFL or authority to tell detractors to screw off. Breaking backward compatibility is kinda a big thing in the web because most of the web is still running legacy stuff.
These kind of things don't happen without such a person or group who will arbitrarily make decisions. The same reason why better languages like Dart don't get adopted.
These kind of things don't happen without such a person or group who will arbitrarily make decisions. The same reason why better languages like Dart don't get adopted.
Yay, typeof null.
I remember being quite surprised to see the Property Accessors RFC for PHP get declined, largely on the basis of making the language more complicated.
It annoyed me at the time but I do respect the decision to resist adding every single feature under the sun.
It annoyed me at the time but I do respect the decision to resist adding every single feature under the sun.
[deleted]
Based on Crockford, when tail recursion optimization lands, meaning soon. It's getting ridiculous now, with a super blurry line between language features and built-in utils
> It's getting ridiculous now, with a super blurry line between language features and built-in utils
I think part of the problem is that there isn't really a standard library for JS, just a bunch of global variables that are automatically there when your program starts
I think part of the problem is that there isn't really a standard library for JS, just a bunch of global variables that are automatically there when your program starts
We don't ask ourselves that of websites or apps, why would we ask it of programming languages?
> We don't ask ourselves that of websites or apps
To be fair, yes we do.
Most websites and apps have an additional advantage of not necessarily caring about backwards compatibility over decades and can cut out features that don't work out or are obsolete, something that may never be possible with JavaScript.
And, just like languages, apps that do become lumbering beasts are often abandoned for rewrites or new apps with similar functionality but streamlined of all that historical baggage.
> why would we ask it of programming languages?
TC39 member Mark S Miller answered this question well in "The Tragedy of the Common Lisp, or, Why Large Languages Explode"
https://mail.mozilla.org/pipermail/es-discuss/2015-June/0433...
There is definitely a balance, but any language ignores this question at its peril.
To be fair, yes we do.
Most websites and apps have an additional advantage of not necessarily caring about backwards compatibility over decades and can cut out features that don't work out or are obsolete, something that may never be possible with JavaScript.
And, just like languages, apps that do become lumbering beasts are often abandoned for rewrites or new apps with similar functionality but streamlined of all that historical baggage.
> why would we ask it of programming languages?
TC39 member Mark S Miller answered this question well in "The Tragedy of the Common Lisp, or, Why Large Languages Explode"
https://mail.mozilla.org/pipermail/es-discuss/2015-June/0433...
There is definitely a balance, but any language ignores this question at its peril.
Because languages that have few but powerful concepts are easy to use.
I also believe that we do ask these questions about apps. Sometimes less is more.
Note: I feel most proposals today are sane.
I also believe that we do ask these questions about apps. Sometimes less is more.
Note: I feel most proposals today are sane.
More is not better.
I always like the old saying "it's not done until you can't remove any more". Adding features doesn't make a thing better, it just makes it more complicated.
I always like the old saying "it's not done until you can't remove any more". Adding features doesn't make a thing better, it just makes it more complicated.
But in case of languages you don't have to use that feature. And it's there for a reason, and that is that it makes certain class of things much easier to solve/implement/model/approach.
And if you don't work in that subfield, you don't have to know that part of the language. (Just as if you don't do compiler development you don't need to know Assembly mnemonics, and you don't have to know how many cycles a a particular microcode takes, and so on. You just use perf if you want to, and see that duh, it's too much, let's use -O3... or ask an expert. Or look into it yourself.)
But when you encounter something new in a language, you can learn about it. If it's there because it made something elegant, great. If not, refactor it. Make it simpler.
But this is the same Deletionist approach that is plaguing Wikipedia, just now with the tragedy of commons language, JS.
And if you don't work in that subfield, you don't have to know that part of the language. (Just as if you don't do compiler development you don't need to know Assembly mnemonics, and you don't have to know how many cycles a a particular microcode takes, and so on. You just use perf if you want to, and see that duh, it's too much, let's use -O3... or ask an expert. Or look into it yourself.)
But when you encounter something new in a language, you can learn about it. If it's there because it made something elegant, great. If not, refactor it. Make it simpler.
But this is the same Deletionist approach that is plaguing Wikipedia, just now with the tragedy of commons language, JS.
> But in case of languages you don't have to use that feature. And it's there for a reason, and that is that it makes certain class of things much easier to solve/implement/model/approach.
You can choose for your code, sure, but you can't choose for everyone else's code. This is brought up whenever C++ complexity threads start. Sure you can choose to not use template metaprogramming or whatever, but some library will use it, and then pow you're using it too.
You can choose for your code, sure, but you can't choose for everyone else's code. This is brought up whenever C++ complexity threads start. Sure you can choose to not use template metaprogramming or whatever, but some library will use it, and then pow you're using it too.
You don't have to use that library.
And as I've mentioned, that library started to use it for a reason.
If you use a library that just starts using expensive features (like templates in C++), just because they think they're cool, then I regret to inform you, that you already depend on a bunch of script kiddies.
This is the same thing as we always discuss with functional programming and all those extremely complicated category-theory heavy con-fuck-structs. They make sense in a setting for some problems. ( https://stackoverflow.com/questions/5057136/real-world-appli... )
But it's very much like a special weapon that is large, and heavy, and only those can handle it that are blessed by the priests of The Temple of Homotopy Type Theory, or whatever, and so on. So mere mortals should not touch it.
And in a proper library, those beasts are locked up well, encapsulated.
It's the language's (or the lib's) shortcoming if you can't interface with the library, can't apply parameters to the library without knowing the hairy internals.
And as I've mentioned, that library started to use it for a reason.
If you use a library that just starts using expensive features (like templates in C++), just because they think they're cool, then I regret to inform you, that you already depend on a bunch of script kiddies.
This is the same thing as we always discuss with functional programming and all those extremely complicated category-theory heavy con-fuck-structs. They make sense in a setting for some problems. ( https://stackoverflow.com/questions/5057136/real-world-appli... )
But it's very much like a special weapon that is large, and heavy, and only those can handle it that are blessed by the priests of The Temple of Homotopy Type Theory, or whatever, and so on. So mere mortals should not touch it.
And in a proper library, those beasts are locked up well, encapsulated.
It's the language's (or the lib's) shortcoming if you can't interface with the library, can't apply parameters to the library without knowing the hairy internals.
OK, so let's take the case of the proposed "includes" feature.
This is syntactical sugar. Replacing indexOf(x)=-1 with includes(x) does nothing else than make the code easier to read, allegedly. The new function provides a shorter way of expressing a single case that indexOf already covers. There are no new capabilities introduced to the language here.
So it's a straight-up coin-toss between "easier to read" and "having to be aware of one more method". I tend to come down on the "no thanks" side of this coin-toss.
Ruby suffers from this, imho. My favourite example is select/reject on arrays. They do exactly the same thing, with the logic on the block reversed. Having to know that there's a reject method (and when to use it) is more mental effort than reading the block logic the other way around, in my opinion.
This is syntactical sugar. Replacing indexOf(x)=-1 with includes(x) does nothing else than make the code easier to read, allegedly. The new function provides a shorter way of expressing a single case that indexOf already covers. There are no new capabilities introduced to the language here.
So it's a straight-up coin-toss between "easier to read" and "having to be aware of one more method". I tend to come down on the "no thanks" side of this coin-toss.
Ruby suffers from this, imho. My favourite example is select/reject on arrays. They do exactly the same thing, with the logic on the block reversed. Having to know that there's a reject method (and when to use it) is more mental effort than reading the block logic the other way around, in my opinion.
Understandability should be the No1 feature of code. Basically interacting with code should be as smooth as possible. Spending cognitive effort to parse all those != -1 and unless select() takes its toll.
I'm not saying knowing one more function is cheap. And I agree Ruby has interesting constructs, but I think plus one function/method is a lot cheaper than to mentally parse all those inheritance/monkey-patching rules.
The same goes for `new` in JavaScript. It does something, but it uses functions, and don't forget .prototype (and so on), and that was hard to grok, so now we have classes too, but that's not just syntactic sugar. But JS is/was a pretty bad language at the start, so something must "had to be done".
And that's why it's important to consider new features, language complexity and so on while considering the particular language's warts. Just adding classes because classes are cool is foolish, but adding classes to bring some sanity to JS is fine.
Of course, there's also subjective priorities. But even ASM has too many opcodes, but at least the syntax is dead simple, but you lack cross-platform-ness, so there's C, which seems simple and low level, but it comes with a tome of undefined behavior and requires hand-rolling everything, hence higher level languages, that are hard to get right. And computer languages evolved a lot, as computing and programming itself did, a-a-and the big old languages C++/Java (and JS too) tried to handle this change, and that's how we got here. (Think of the Java Modules [JSR-376] process, how it was an uphill battle from the first minute, how it is at the same time too simple to replace OSGi [for example, because it lacks lifecycle management - which was never a stated goal, but sshhh], but too much to introduce without breaking changes [which is actually not true, because "automatic modules" sort of deals with legacy JAR files, but sssh again], and it has almost nothing to do with the language itself, it's just an ecosystem thing. But people are afraid of change, usually understandably. Compared to that TC39 is pretty nice.)
I'm not saying knowing one more function is cheap. And I agree Ruby has interesting constructs, but I think plus one function/method is a lot cheaper than to mentally parse all those inheritance/monkey-patching rules.
The same goes for `new` in JavaScript. It does something, but it uses functions, and don't forget .prototype (and so on), and that was hard to grok, so now we have classes too, but that's not just syntactic sugar. But JS is/was a pretty bad language at the start, so something must "had to be done".
And that's why it's important to consider new features, language complexity and so on while considering the particular language's warts. Just adding classes because classes are cool is foolish, but adding classes to bring some sanity to JS is fine.
Of course, there's also subjective priorities. But even ASM has too many opcodes, but at least the syntax is dead simple, but you lack cross-platform-ness, so there's C, which seems simple and low level, but it comes with a tome of undefined behavior and requires hand-rolling everything, hence higher level languages, that are hard to get right. And computer languages evolved a lot, as computing and programming itself did, a-a-and the big old languages C++/Java (and JS too) tried to handle this change, and that's how we got here. (Think of the Java Modules [JSR-376] process, how it was an uphill battle from the first minute, how it is at the same time too simple to replace OSGi [for example, because it lacks lifecycle management - which was never a stated goal, but sshhh], but too much to introduce without breaking changes [which is actually not true, because "automatic modules" sort of deals with legacy JAR files, but sssh again], and it has almost nothing to do with the language itself, it's just an ecosystem thing. But people are afraid of change, usually understandably. Compared to that TC39 is pretty nice.)
I don't understand why doesn't an ECMAScript2 exist at this point, instead of just trying to patch JavaScript. The whole reason JScript and others ultimately failed were because they were not standardized. How hard is it for browser vendors to say "we'll implement ECMAScript2, whatever it is" so that we can all have a sane language to work with (while we wait for WebAssembly).
To some extent there is, in that the javascript VMs can treat certain sorts of scopes (like Modules) differently because they know that those did not exist at an earlier time when certain bad behaviors were common.
They debated quite a bit while working on ES6 about having a different script type to make more breaking changes, but they decided that this would be bad for evolution on the web (see the adoption of Python 3, for example)
They debated quite a bit while working on ES6 about having a different script type to make more breaking changes, but they decided that this would be bad for evolution on the web (see the adoption of Python 3, for example)
To expand: use strict is always in force in ES6.
In ES6 modules, it is. In other code, ES6 is backwards compatible with ES5 (i.e., code is strict mode iff there's a "strict mode" declaration).
Oops. Left off that key word :) Yes, ES6 modules.
That's not correct: a small percentage of the JS community (maybe <1%) use TC39 modules (which enforce strict mode) vs just using npm.
I am correct because I'm talking about ECMAScript 6. http://www.ecma-international.org/ecma-262/6.0/
If you're talking about Node.js or JScript or something else, then that's different.
If you're talking about Node.js or JScript or something else, then that's different.
In node perhaps.
They're extremely common in the front end world - all the fancy SPA frameworks and build systems promote & use them extensively.
They're extremely common in the front end world - all the fancy SPA frameworks and build systems promote & use them extensively.
That's what Dart was supposed to be, in Google's eyes. The problem is both that it needs buy-in from all browser vendors (and the webdev community), and more importantly, that you'll now need to support both Javascript and the new language indefinitely. Especially considering that new mistakes will be made with the new language, and new quirks introduced, that doesn't sound that attractive.
Google gave up on dart as an browser language quite a while ago. It now sees use server-side and in flutter (a native UI layer).
My understanding is that they use it for most of their front-end work but compile it to javascript. See angular-dart.
You are completely correct. I was considering that to be like ocaml, kotlin, scala, etc which transpile to JS. For what it's worth, I think either ocaml or SML is far better than dart for compiling to JS, but dart is far better than typescript (and has a more sound type system). It's not a huge wonder that Google apparently uses angular-dart instead of the typescript version.
Yeah, I said that's what it _was_ supposed to be ;)
Obviously, Javascript needs to be complex enough to bootstrap the Singularity.
If that's how it goes, we needn't worry. It'll be an endless chain of AIs, each spending all its time designing a new and better language to write the next AI in. As we know full well by now, the process is so fascinating in and of itself, there's little else that they will have time for.
> Class Decorators (Stage 2)
Does it means both Typescript and AngularJS implement/use an experimental feature that is still under discussion as of now, in production? this is a bit risky.
Does it means both Typescript and AngularJS implement/use an experimental feature that is still under discussion as of now, in production? this is a bit risky.
Yep, interestingly the decorators proposal has changed significantly since it was in stage-0.
So much so that this exists: https://github.com/loganfsmyth/babel-plugin-transform-decora...
So much so that this exists: https://github.com/loganfsmyth/babel-plugin-transform-decora...
To be fair, though, you must explicitly opt in to using decorators in TypeScript via --experimentalDecorators, and the documentation for said switch states: "Decorators are an experimental feature that may change in future releases."
Angular uses the decorator syntax, with a preprocessor that gives it different meaning.
Really wish there was more momentum on adding a safe access operator. Even Ruby has that now, it's disappointing that we still don't have it in JS.
It's at Stage 1 https://github.com/tc39/proposal-optional-chaining
and babel plugin is coming here https://github.com/babel/babel/pull/5813
and babel plugin is coming here https://github.com/babel/babel/pull/5813
> Even Ruby has that now
Are you implying that Ruby is a backward language ? :/
Are you implying that Ruby is a backward language ? :/
you mean you wish you had an Option monad, right? ;-)
We have deep-value and deep-reduce easily available:
https://www.npmjs.com/package/deep-value https://www.npmjs.com/package/deep-reduce
https://www.npmjs.com/package/deep-value https://www.npmjs.com/package/deep-reduce
Really looking forward to class decorators.
Decorators are one of those things that I've not seen a use case that sells them to me.
Like... I'm sure one day I'll see something and it'll just click, but not there yet.
Like... I'm sure one day I'll see something and it'll just click, but not there yet.
When marshaling classes in and out of xml/json decarators can be added to properties to change the name of the equivalent Json field value as well as indicating if it's optional or not. Orms use decators to map object to relational tables the may have different field names, expressing key values, etc
None of that sounds particularly hard, complex, or tricky without decorators though.
Like, I get they can be used for stuff but why are they a better option?
So far - based on the responses here - it appears to be syntax for syntax sake and no practical benefit.
Like, I get they can be used for stuff but why are they a better option?
So far - based on the responses here - it appears to be syntax for syntax sake and no practical benefit.
It's just sugar but it's less code and I find it easy to read at least in go.
It’s not really less code though. It’s about the same but with an syntax that obfuscates where the logic happens.
Terse at the usage point yes, but it swaps clarity for brevity. A sometimes useful trade off to be sure but... not sure I’ve seen any demonstration of benefits here.
Terse at the usage point yes, but it swaps clarity for brevity. A sometimes useful trade off to be sure but... not sure I’ve seen any demonstration of benefits here.
Well, in C#-land, we often use / abuse attributes to get information about a class or property at runtime. This way, framework or library code can inspect entities that you've authored, and dynamically deal with them. Perhaps a decent example is validation, where a declarative style has gained a lot of popularity. A JS example might be:
We can argue terseness vs verbosity, implicitness vs explicitness all day - I'd argue that for certain basic things that you do highly frequently, a terse and implicit style is not a bad thing. It tends to increase the signal-to-noise ratio of your code, allowing the developer to focus on things that really are interesting, and not have to read through a lot of boilerplate.
@required firstName;
We can argue terseness vs verbosity, implicitness vs explicitness all day - I'd argue that for certain basic things that you do highly frequently, a terse and implicit style is not a bad thing. It tends to increase the signal-to-noise ratio of your code, allowing the developer to focus on things that really are interesting, and not have to read through a lot of boilerplate.
Hmmm a required flag is a nice idea (but better exposed using interfaces as an idiom I’d argue) but it’s not selling me on the wider use case.
If we were talking about very basic things then yes, sure, but I’d also argue that if they are truly basic then we could restrict decorators to built-in ones only (as those are the basics).
Much like there are “magic” Symbols like Symbol.iterator.
If we were talking about very basic things then yes, sure, but I’d also argue that if they are truly basic then we could restrict decorators to built-in ones only (as those are the basics).
Much like there are “magic” Symbols like Symbol.iterator.
That's interesting. My knowledge of JS is a bit lacking, so I'm struggling to see the equivalence of the interfaces approach. E.g., is it possible to parametrize interfaces with actual values, such as @maxLength(20)? Also, how do you apply interfaces down to the field-level, where they are of primitive types, such as number or string?
That feels like a job for getters/setters, no?
I guess it depends what style you favour. I can't imagine using getters/setters like that in JS today, and not have major pains from it (things like not being able to use data binding frameworks easily, etc).
I'm the same way, except less sure that I'll find something that will change my mind.
Maybe “sure” was overly optimistic. “Hopeful” might be better put.
I like the idea but I’ve yet to see a case that leads to better Code than other implementations.
I like the idea but I’ve yet to see a case that leads to better Code than other implementations.
In angular2 they are for example used for dependency injection, which works really well.
Other use cases that I see are for example automatically generating [de]serialization code for members based on decorators and their values (like how Annotations are used in C# and Java serialization frameworks or tags in Go).
There are also web frameworks popping up which use decorators for routing and parameter binding in a similar fashion how some Java frameworks work.
Other use cases that I see are for example automatically generating [de]serialization code for members based on decorators and their values (like how Annotations are used in C# and Java serialization frameworks or tags in Go).
There are also web frameworks popping up which use decorators for routing and parameter binding in a similar fashion how some Java frameworks work.
So syntax to his bad application design & code patterns behind? That’s an argument against them surely?
That... doesn't help. From what I see there I get harder to follow, non-idiomatic to anything in JS, code but the bonus is a terser syntax?
Great...?
I really hope there's a better use case for them because this is not selling me. Literally none of that post is a compelling case.
I get the cleaner syntax, that's nice, but it also means now I have to look up what that does. And that decorated properties example? Yikes that's awful - it looks like a code-smell frankly.
But all that initial urrrgh factor could be removed by showing me a use case that makes the code significantly more elegant to do `@foo bar` rather than `foo(bar)`.
Great...?
I really hope there's a better use case for them because this is not selling me. Literally none of that post is a compelling case.
I get the cleaner syntax, that's nice, but it also means now I have to look up what that does. And that decorated properties example? Yikes that's awful - it looks like a code-smell frankly.
But all that initial urrrgh factor could be removed by showing me a use case that makes the code significantly more elegant to do `@foo bar` rather than `foo(bar)`.
I for one am not. What is wrong with calling a plain function?
You need to use `.bind()` to set the context, or switch to using arrow functions. Both methods are sub-optimal. `@autobind` solves that.
Why is
@autobind
foo() {
// ...
}
foo = () => {
// ...
}
?Please, Nothing is ever _more optimal_.
Bad example, checkout mobx or core-decorators.
@computed get value() { return this.a + 1; } @readonly bar = 5;
@computed get value() { return this.a + 1; } @readonly bar = 5;
The use of decorators in Anguar 2/4 is also very well done, IMHO. They allow your class to focus on its business logic, rather than the minute details of how Angular expects it to interact with the rest of Angular.
There's a reason all the most common languages have them, concealing complexity is a way to reduce cognitive overload and therefore, bugs.
There's a reason all the most common languages have them, concealing complexity is a way to reduce cognitive overload and therefore, bugs.
Oh please. Decorators will never beat plain old functions when it comes to flexibility.
C will never beat plain old assembly when it comes to flexibility.
Hardly a fair comparison. Decorators exist in Python and other languages primarily because they either don't have lambdas or have bad ones. JS doesn't suffer from those problems, so the mental overhead of the additional syntax has a much lower payoff (and one that I believe isn't worth the trouble).
[deleted]
Really wish they had included function decorators too.
https://github.com/wycats/javascript-decorators/issues/4
https://github.com/wycats/javascript-decorators/issues/4
I wish we could get macros then we could make our own decorators... (macro support in typescript would be awesome)
> TC39 is currently working on over 30 active proposals. What else does the future hold in store? These days we download our packages from npm.
I am surprised that no more mentions of NPM were made. I hope that commitee TC39 addresses the topic of NPM and tries to create a new version that is standarized and that elliminates the serious flaws of NPM, which for me are one of the major hindrances to adopting Node.js for things that go beyond prototyping.
I am surprised that no more mentions of NPM were made. I hope that commitee TC39 addresses the topic of NPM and tries to create a new version that is standarized and that elliminates the serious flaws of NPM, which for me are one of the major hindrances to adopting Node.js for things that go beyond prototyping.
No mentions of npm are made because this is about language specification not the broader ecosystem around javascript.
Package managers are completely detached from language specifications so that they can evolve independently.
Package managers are completely detached from language specifications so that they can evolve independently.
Out of curiosity, have you seen the latest changes to npm? Since they've added lockfiles I've yet to have any issues with dependency management, really.
Thanks for your reply, Sean.
Googling on lockfiles i found out more about the features of the Yarn package manager. Perhaps that's what I should use.
However what i meant with my comment is that I feel that package managers should be standarized into a language -- as long as the package registry is not private but can be pointed to whatever URL one wants.
Googling on lockfiles i found out more about the features of the Yarn package manager. Perhaps that's what I should use.
However what i meant with my comment is that I feel that package managers should be standarized into a language -- as long as the package registry is not private but can be pointed to whatever URL one wants.
Well, npm got faster over the years and with v5 they got consistent hashing for versions, which should make deployment much safer.
yarn is a great alternative to npm
Is there any plan for 64-bit integers?
There is some work underway.
https://github.com/tc39/proposal-bigint/blob/master/README.m...
https://github.com/tc39/proposal-bigint/blob/master/README.m...
I would argue that the future of JS looks bleak when you effectively can't have any meaningful discussions about proposals if you are not in the committee (the author just ignored the issue for half a year, then closed and locked it): https://github.com/tc39/proposal-dynamic-import/issues/35