A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Putting APIs in ECMAScript


Continuing the discussion from A ZIP API in the browser?:

I don’t think having a large “standard library” built into the language spec and language VMs is a worthwhile or interesting goal. Different environments will want different libraries available, especially given the different constraints. For example, downloading and loading code has almost negligible cost server-side, where startup time is unimportant, whereas it has a large cost client-side. Other cases are resource-constrained embedded devices versus the relative plenitude of our phones and desktops; having to ship a ZIP API (and a crypto API, and a URL-resolution API, and a safe-HTML-encoding library, and…) to such devices is prohibitive.

Saying that a ZIP API is a language feature seems, on its face, to be pretty weird. Maybe it’s useful in both Node and the browser, in which case both Node and the browser can implement the ZIP API spec. But ZIP is on a completely different level than Object, Promise, Map, GeneratorFunction, or even RegExp.


Related idea: TC-39 could create a forum on uservoice.com (like what Mozilla did recently for FF DevTools) for suggesting and voting on potential APIs. I’d be interested to see what the community wants.


As I understand there is intent to make some std libs though, right? Just post ES6…? I know console was discussed in this light and it makes sense to me - we put together https://github.com/DeveloperToolsWG/console-object in prep for this


Agreed, for ZIP. None of this applies to setTimeout though.


+1, I’d like to see WebWorker API in ECMAScript.


Regarding ES contributions from WICG, I’m less interested in the ES/JS distinction and more interested in getting features in the language for properties already being tracked in every major implementation.