proposal-built-in-modules
proposal-built-in-modules copied to clipboard
tc39
JavaScript standard library contents
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.
enhanced promises
- no leaking promises-aplus/promises-spec#179
- propagated cancelation
- splitting
theninto 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.
Changing something that’s already in the language would need its own proposal; i think the standard library would be for adding new things.
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.
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.
WHATWG URL should be normative.
await JSON.parse() and await JSON.stringify() or similar
Anything that validates ECMAScript internal stuff. e.g. https://mothereff.in/js-variables
@Mouvedia Would uuid make sense as part of WebCrypto? https://github.com/w3c/webcrypto/issues/215
@mathiasbynens 's Unicode RegExp properties should help with making that checker more efficient!
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 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.
@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.)
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 https://github.com/tc39/proposal-javascript-standard-library/issues/16#issuecomment-447916074
It would be great to be able to access object properties without having to do something along the lines of
const prop2 = obj && obj.prop1 && obj.prop1.prop2
Something like the lodash _.get function, or Angular's elvis operator in the templates (obj?.prop1?.prop2?)
I'm not super-keen on _.get because it's turning the property path into a string, which is not great from a typing and build checking point of view, but I use it as an example of desired functionality.
My two longstanding bugbears with the JS standard library (going back to my pre-jQuery days) are:
- A better interface for dealing with cookies (i.e. doesn't involve directly manipulating a string - something like Web Storage).
- A parser/constructor for URLs like Python's urllib.parse (other languages' standard library methods for dealing with URLs are also available).
For a language that spends a lot of its time running in a browser these seem like obvious candidates for a standard library.
@decadecity I'm wondering if the solutions at the web level, currently shipping in browsers, are enough for your use case.
- Does Web Storage solve the issue for you, or are there remaining problems?
- Does the WHATWG URL API solve this issue for you?
@littledan
- Web Storage is fine for client side storage but doesn't do cookies :stuck_out_tongue: Directly manipulating the
document.cookiesstring is a terrible API, I'd like to see something like the extension cookies API. - The URL API looks like it's about right, thanks :+1:
@decadecity Work is ongoing to evolve the cookie API itself at https://github.com/WICG/cookie-store . TC39 is probably the wrong place to advance work in this area, as we focus on things that don't involve I/O. Cookies don't mean much outside of the Web.
In terms of what we can see people using, lodash is the most depended upon library that would be potentially appropriate to exist in core: https://www.npmjs.com/browse/depended
It's a bit harder to break down which functions are used the most, but you can get an idea here: https://www.npmjs.com/search?q=lodash&ranking=popularity
There is also a minimal version of the library: https://github.com/lodash/lodash/wiki/Build-Differences
No, the JS standard library should not be minimal. Part of the reason there's so many variations on the underscore theme is that there's a lot of really basic stuff missing from the language (like deep copy.)
Unfortunately it's not clear where feature requests belong. While I was writing out a flood, I was told "not here. Maybe on issue 16."
There's dozens of easy one-liners that would massively improve the language if gatekeepers would permit them
I'll copy pasta a bunch right now if someone tells me where to put them
@StoneCypher I'm glad you came here to do additional brainstorming for contents. For JavaScript one-liners, maybe could you make your own repository or gist for development and link to it from here?
Somehow I feel like the input from @kgryte could be useful to this discussion ;)
Would be really nice if there was an official place to give people recommendations for a more complete standard libary
There's a whole lot of donation languishing in repos that gatekeepers don't look for
JS could be an amazingly easier language with very little work on anyone's part if the gatekeepers would facilitate donation
In erlang, for example, there is a bug tracker where I can go, add a ticket with some code and some appropriate tags, and if my code isn't garbage and makes sense, there's a good chance it'll show up in the next standard library under some very different name
Recommendations I gave to Ian Hicks almost 20 years ago and gave code for are being invented this year and treated as important and ground breaking ☹️
Javascript should have a process for letting people who aren't friends with standards maintainers be helpful too
I'm just going to go ahead and put what I wrote yesterday into a ticket
If I put it in my own repo nobody will ever look at it and it will die on-site