JavaScript standard library contents

[littledan]

The JavaScript standard library is very minimal. Is this how it should be? What should we add?

Note, the purpose of this repository is to develop the infrastructure for built-in modules, not the contents. However, I know many of you have ideas for the contents as well, so let's brainstorm those in this issue exclusively.

[Mouvedia]

enhanced promises

• no leaking chain of never resolved promises create memory leaks promises-aplus/promises-spec#179
• propagated cancelation
• splitting then into different methods

@littledan is this issue a dump for proposals? If that's the case I don't think we will ever be able to close it.

[ljharb]

Changing something that’s already in the language would need its own proposal; i think the standard library would be for adding new things.

[Mouvedia]

Changing something that’s already in the language would need its own proposal

@ljharb If the change is too radical or breaking, it has to be externalized: an alternative with another name to avoid confusion; future comes to mind in my case.

[littledan]

I meant this as a brainstorming thread. What we talk about here might graduate into proposals. As @ljharb says, let's try to focus on additions of new features, rather than changes to existing things (it's not clear how to expose what you're talking about as a built-in module). If this thread gets too unwieldy, we can close it.

[Mouvedia]

Composable?

[jasnell]

WHATWG URL should be normative.
await JSON.parse() and await JSON.stringify() or similar

[NarHakobyan]

Would be nice to have promise cancelation

[Mouvedia]

uuid?

[Mouvedia]

Anything that validates ECMAScript internal stuff.
e.g. https://mothereff.in/js-variables

[littledan]

@Mouvedia Would uuid make sense as part of WebCrypto? w3c/webcrypto#215

[littledan]

@mathiasbynens 's Unicode RegExp properties should help with making that checker more efficient!

[Mouvedia]

That validator is just an example. My point is that the language should expose its own validators/assertors.

That would permit to have a basis for other interfaces (like the DOM).
e.g. I had to make my own class/id assertors (html/css)

[Mouvedia]

@Mouvedia Would uuid make sense as part of WebCrypto? w3c/webcrypto#215

I don't know. Last time I checked the polyfill was enormous—it was almost impractical.

[littledan]

@Mouvedia Well, the idea would be that you just use uuid if you don't have the built-in one. (uuid actually uses WebCrypto in browsers today.)

[Mouvedia]

The idea of futures is something that should be pursued; in the same way that XMLHttpRequest was retroactively redefined in terms of fetch, we could have Promise be redefined in terms of Future where futures are more granular and hence give more control to the user.

@NarHakobyan #16 (comment)