1 of 19

Expanding the JS standard library:

What are our goals?

Bradley Farias and Daniel Ehrenberg

TC39 January 2017

2 of 19

Goal of this presentation

  • JS has a relatively small standard library
  • Is “small core” still best for us?
  • What to add? And how?

​

Group Visioning!

3 of 19

Abbreviated history of the JS standard library

  • ES1: Number, String, Array, Math, Date
  • ES3: RegExp, string improvements, Error, URI handling
  • ES5: Array methods, JSON, more reflection
  • ES6: Map, Set, WeapMap, WeakSet, Promise, Math functions, TypedArrays, DataView, subclassable builtins, iteration protocol
  • ES2016: Array.prototype.includes
  • ES2017: SharedArrayBuffer
  • ES2018: RegExp features?, Promise.prototype.finally?

4 of 19

Proposed/requested library features

  • Observables
  • RegExp matchAll, replaceAll
  • Date replacement
  • More Math functions
  • Set methods
  • Map/Set with configurable hash
  • Itertools
  • Global
  • Promise.try
  • Object.deepFreeze
  • …
  • How do we choose?

5 of 19

What to add?

6 of 19

Optimizability

  • A new built-in may be implementable faster in the engine than in user-level JS
    • Load time
    • Execution time

7 of 19

Expressiveness

  • Impossible to implement otherwise
    • Example: WeakMap

8 of 19

Reduce dependence on external libraries

  • Things that are used a lot?
  • Purely ergonomic features?
  • Reducing the size of code loaded (load time)?
  • Are JS builtins expected to be higher quality (more correct)?

​

  • Where is the bar for importance?

9 of 19

Design

10 of 19

In what form?

  • Designing to standardize existing practice
  • Do a new "good design"
  • Something in between?

​

11 of 19

Layering

12 of 19

Where do we sit relative to embedders?

  • Test case: TextEncoder.
    • Leave in WHATWG, or bring to JavaScript?
  • Option: the standard library should grow to subsume things that are need by multiple embedders
  • Option: When the Web has a library, JS shouldn’t duplicate it; encourage more to expose it

13 of 19

Spec machinery

14 of 19

“JSIDL”

  • ECMASpeak has a lot of boilerplate
  • Web Platform specs define things with WebIDL, a class-like syntax
  • Should we do something like this?

15 of 19

Built-in modules

16 of 19

Should new library features be in built-in modules?

  • Vision (?):
    • from “js:itertools” import { range };

​

  • Problem: How do we do polyfills?
    • Need to be able to import the built-in version, patch it, and re-export a modified version
    • Is it worth the overhead of these new APIs?
  • Problem: Consistent vision for the platform
    • Will all new things be in modules?
    • Will we clean up and modularize the old things?

17 of 19

Next steps

18 of 19

Agree on a vision

  • We have discussed these questions many times
  • Let’s work this out generally and not burden individual proposal authors with it

19 of 19

Proposed exercise:

Comparative study of libraries

  • Vision: a big spreadsheet
  • What library features are common among languages?
  • Which JS libraries do people use most frequently, and which features within those?