Should this effort be split into two specs?

[dead-claudia]

A standard library for JS would be nice, and I do feel this effort could have an incredible impact upon the community. However, I feel this effort should be divided into two specs, the ES core spec and a separate runtime standard library spec, specifically informed by the intersection of what developers need from Node, browsers, browser extensions, and other similar hosts:

• Simple data processing and general-purpose data structures belong in the ES spec proper, specifying what implementors should expose.
  • Temporal
  • Binary I/O stream primitives, separate from observables since they are typically managed at a higher level than simple observables of bytes
  • Common conversion APIs for things like URL escaping (for URL templates), Base64 conversion, and similar
• Stuff that's at least in part platform-dependent belong in a new spec that deals with what hosts should expose:
  • Filesystem APIs - Web pages lack access to most of this, but pretty much everything else needs this to some degree.
  • Stream and buffer encoding/decoding
  • High-level networking APIs, including:
    • A generic fetch(string, opts?) part with associated response APIs
    • Web socket APIs
  • Event loop APIs, including equivalents for setTimeout and setInterval
  • Worker APIs, including web workers and Node workers
  • Object inspection - browsers may choose to censor internal fields, while Node may choose to expose them.
  • System introspection like CPU statistics, available memory, and similar - browsers obviously shouldn't expose most of this to general web pages for privacy reasons, but extensions and native apps frequently need this for reasons varying from loading native executables to knowing how to ideally parallelize something.
    • Chrome extensions expose this under system.cpu, system.memory, and system.storage
    • Node exposes most of this in its os module and the rest in its process global/module
    • Should the current monotonic CPU time also be included here? I think so - it'd limit the promulgation of host-dependent stuff in the core language spec itself (which has caused problems in the past already), and it'd make it much clearer this is a low-level, system-level operation. It'd also mean temporal wouldn't need that concept - it'd just be purely data-driven.
  • Native cryptography APIs - this almost always delegates to a native system or host crypto implementation, so it doesn't belong in the core spec.
  • WebAssembly loading - this is as host-dependent as module loading.
  • Off-screen GPU access with required CPU fallback, useful for image processing and large-scale data processing on server-side and client-side

Of course, each of these would have appropriate hooks for permissions checking and not all of them have to be supported by the host.

---

This is in part spurred by this bug as well as recent ES Discuss discussion, but I also see it as a chance to bring some consistency to environments, something greatly beneficial to users at large.

I don't see this as critical, but I do see the use in defining what the line is between what should be in the core spec and what should be required of the host (as opposed to the implementation), and I do feel that line needs held to strongly so people understand why certain things aren't going to make it into the spec.

Having this TC39-side also means it's easier to design language features around this core, and WHATWG can focus more on HTML semantics. It's fewer concerns to integrate, and it makes for an easier time figuring out how JS features operate concretely. (In particular, requests, timers, and file streaming could make for a nice case study on how cancellation works out in the real world and it'd make it easier to work that out in more than toy examples.)

[littledan]

I agree that we should focus, in this repository, on your first bullet point above, and that we can leave I/O and event loop stuff to host environment specifications. Maybe we can clarify this in the README.

[kaizhu256]

i agree standardizing conversion APIs are a priority and common painpoint in UX-workflow programming.