Logistics
Facilitator(s)
@aapoalas (Nova JavaScript engine)
Summary
JavaScript is generally known to be a language with warts and oddities way larger than its popularity would suggest. In some ways these exist precisely because of the popularity of the language. They are also very much here to stay as the cost of removing them is truly incalculable, and trying to remove them generally is a waste of time and energy.
However, that does not mean that we couldn't consider what a "sane subset" or subsets of JavaScript would look like. If such a subset were to be created, it would not appear Node.js, or Deno, or browsers any time soon if ever. But in embedding use-cases where the embedder controls both the JavaScript code and the engine running it, opting out of many of the weirder and less robust parts of JavaScript in exchange for a smaller, faster, or better optimisable whole might well be worth it.
Some possible subsets to whet the appetite are:
- Removal of sparse Arrays.
- Removal of Array element descriptors.
- Removal of class private property "stamping" through the constructor return trick.
- Removal of the constructor return trick.
- Throw error on property access miss.
- Remove delete keyword.
- Immutable prototype objects.
- Remove setPrototypeOf.
- Remove FinalizationRegistry, WeakMap, WeakRef, and WeakSet.
- Always-strict.
- Remove thenables.
- Remove Promise subclassing.
- Remove X subclassing.
Some of these are more onerous subsets than others; none of these is meant to be the be-all-end-all subset, these are merely starting points for a discussion: What sort of issues would these kinds of subsets cause? What sort of benefits could JavaScript engines offer users who adopt these subsets?
The one we do not want to discuss in this breakout session is "this'd break the Internet/NPM ecosystem, and therefore cannot be done." It is to be accepted as a premise that any subset would break something somewhere, and that the user is explicit aware of this and accepts that not every piece of existing JavaScript code will work in the subset.
Type
Onsite
Other comments
Hoping for an open discussion on subsets / features you'd like to see gone from your own "sane subset" of JavaScript. Looking for both JavaScript user/embedder viewpoints, and engine developer viewpoints.
Logistics
Facilitator(s)
@aapoalas (Nova JavaScript engine)
Summary
JavaScript is generally known to be a language with warts and oddities way larger than its popularity would suggest. In some ways these exist precisely because of the popularity of the language. They are also very much here to stay as the cost of removing them is truly incalculable, and trying to remove them generally is a waste of time and energy.
However, that does not mean that we couldn't consider what a "sane subset" or subsets of JavaScript would look like. If such a subset were to be created, it would not appear Node.js, or Deno, or browsers any time soon if ever. But in embedding use-cases where the embedder controls both the JavaScript code and the engine running it, opting out of many of the weirder and less robust parts of JavaScript in exchange for a smaller, faster, or better optimisable whole might well be worth it.
Some possible subsets to whet the appetite are:
Some of these are more onerous subsets than others; none of these is meant to be the be-all-end-all subset, these are merely starting points for a discussion: What sort of issues would these kinds of subsets cause? What sort of benefits could JavaScript engines offer users who adopt these subsets?
The one we do not want to discuss in this breakout session is "this'd break the Internet/NPM ecosystem, and therefore cannot be done." It is to be accepted as a premise that any subset would break something somewhere, and that the user is explicit aware of this and accepts that not every piece of existing JavaScript code will work in the subset.
Type
Onsite
Other comments
Hoping for an open discussion on subsets / features you'd like to see gone from your own "sane subset" of JavaScript. Looking for both JavaScript user/embedder viewpoints, and engine developer viewpoints.