mdn
Content suggestion: Mention which ES version a feature was introduced in
What is the new suggestion?
For a given ES feature, there should be a clear label saying which ES specification it was introduced in, e.g. ES2015, ES2020, etc.
Why is it important or useful?
Knowing the corresponding minimum target ES version for a feature informs developers whether they can use it in a project that targets a specific ES version, or whether a polyfill or other solution is required. It also informs the choice of which ES version to target in the first place.
This is particularly important for TS projects, which should target a specific ES version.
How many pages are likely to be needed? Modifications to almost all pages.
How much time do you think this work should take? A few hours? A week? A month?
I swear this feature was available before the site redesign. If the info is already there, displaying it again shouldn't be too much work. A person-week maybe? I have no idea to be honest.
Will the work enable learners or professionals to achieve their goals better?
Yes. Does it address critical needs in the web industry?
Yes. Is the work an operational necessity, i.e. is not having it a security risk?
I don't know whether targeting specific ES version can pose a security risk.
Does the content help make the web more ethical? Probably not.
Other supporting information
N/A
I don't have strong opinions about this, but I'm very much against TS (and SWC)'s approach of cutting by ES versions. The ES versions are pretty arbitrary and correspond to neither semantics nor browser support. Babel's approach of syntax plugins + preset-env is much saner. Also you can read about each version's updates in the spec introduction.
Should this be in BCD instead? @queengooborg thoughts about how this could work?
Technically speaking, both BCD and MDN already do this. While there isn't a specific label or tag or otherwise to indicate the ES version, it is shown in the specifications table, right above the compatibility tables.
In regards to requiring a poly fill to enable certain functionality, the ES version is not a good representation. Browsers and JavaScript engines will not typically implement an entire ES version in one go, but rather gradually implementing individual features. A web developer should refer to the browser compatibility tables to determine what browser version a specific JavaScript feature was implemented in, and add a polyfill if needed based upon that.
I also agree that the way TypeScript utilizes this is unhelpful. Aside from TypeScript, are there other projects that use the ECMAScript version number for targets or otherwise?
Yes, SWC does this as well, although SWC also has an option for browserslist. But TS is the most popular—and TBH, I've often wondered about the ES version of some features (e.g. async functions) myself...
it is shown in the specifications table,
The specification table doesn't point to the ES version it's introduced in. e.g. for https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function, if we are to implement this suggestion, I would expect to see "ES2019" mentioned somewhere.
This information used to be present under the Specifications header. e.g. http://web.archive.org/web/20190819021042/https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise#Specifications
cc/ @schalkneethling Can you convert this into a discussion on mdn/mdn-community ? This needs a broader audience.
I realized this is also proposed in mdn/browser-compat-data#14835—we should discuss in one centralized place.
I would close this and track it in https://github.com/mdn/browser-compat-data/issues/14835 in any case, because this is definitely more related to browser compat. If someone comes around they may convert it to a discussion as well.