By default, features that can be implemented in what the committee calls “userland code” don’t have a strong case to be included in the language. Exceptions can be made when implementing the feature natively would yield significant benefits compared to what’s possible in userland code:
- deep platform integration (e.g. Promises)
- performance or efficiency benefits in terms of load time, run time, or memory usage (e.g. RegExp Unicode property escapes,
Intl features)
- some features are impossible to implement in userland (e.g.
WeakMap)
So far, this has always been discussed on a per-proposal basis. Bradley Farias and Daniel Ehrenberg are currently leading an effort to codify the TC39 committee’s goals on new proposals in general, which would help answer future-facing questions such as “should new library features be in built-in modules?”.
Part of the TC39 committee’s role is to act as a gatekeeper for the JavaScript language. The goal is not to maximize the number of features in the language, but rather to ensure that JavaScript continues to be an attractive language that’s as internally consistent as possible (within the constraints of backwards compatibility).