Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Summary of JavaScript Standard Library (Stage 1) Proposal

Summary of JavaScript Standard Library (Stage 1) Proposal

Tetsuharu Ohzeki

October 09, 2019

More Decks by Tetsuharu Ohzeki

Other Decks in Programming


  1. JavaScript Standard Library • https://github.com/tc39/proposal-javascript-standard-library • Stage 1 (Oct. 9th,

    2019) • It’s still a dream, hope, glorious, and future • Authors & Champions • Michael Saboff (Apple) • Mattijs Hoitink (Apple) • Rename to builtin-module proposal?
  2. Motivation • JavaScript doesn't have standard library mechanism • Far

    from “battery included” • Developer need pay a cost to bundle libraries • download cost, parsing cost, no cache across programs, etc…
  3. Motivation • Extending builtins often almost always causes web- compat

    • @@unscopable (ES2015) • Array.prototype.contains() -> Array.prototype.includes() (ES2016) • Array.prototype.flatten() -> Array.prototype.flat() (ES2019)
  4. Scope • Define a mechanism for enabling a more extensive

    standard library in JavaScript than is currently available • What should be included in “std library”? • Not scope • Other specs will be built on this • e.g. UUID proposal
  5. Semantics • Use import statement • ModuleSpecifier starts with a

    prefix • Import {} from “<prefix>:<module_name>” • This distinguish standard libraries from user’s one
  6. Namespace Prefix • js: • import { bar } from

    “js:foo”; • Other specifications can introduce an arbitrary prefix • “node:”, “web:”, “intl:”, “device:” etc… • TC39 hosts a repository to manage them?
  7. Freezing Exports • All exported objects & classes are frozen

    • Prevents to extend by other modules • Decrease a risk of web compatibility for the future
  8. Polyfilling Use Cases • Intended only these: • Add missing

    parts of the standard library • Update incomplete implementations • Patch broken parts of the standard library • There is a rough consensus to provide polyfill mechanism • …but details are still under considerations • For web: use Import-Maps proposals?
  9. How to use from classic script? • No Proposal yet

    • By the meeting note of TC39 July 2019, there was a discussion about that it is required as a fundamental feature to support importing from classic script • No GitHub Issue? • IMO, I feel it’s better we should separate it to a new proposal • Anyhow, developer can use webpack/rollup to generate classic script instead of writing a classic script directly • Developer need a consensus to allow to transform them
  10. Relations with Web Std? • By meeting notes of TC39,

    I feel there has not been concrete consensus yet • Google vs Apple for a long time……