New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JavaScript standard library contents #16

Open
littledan opened this Issue Dec 17, 2018 · 80 comments

Comments

Projects
None yet
@littledan
Copy link
Member

littledan commented Dec 17, 2018

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

This comment has been minimized.

Copy link

Mouvedia commented Dec 17, 2018

enhanced promises

@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

This comment has been minimized.

Copy link
Member

ljharb commented Dec 17, 2018

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

This comment has been minimized.

Copy link

Mouvedia commented Dec 17, 2018

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

This comment has been minimized.

Copy link
Member Author

littledan commented Dec 17, 2018

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

This comment has been minimized.

Copy link

Mouvedia commented Dec 17, 2018

@jasnell

This comment has been minimized.

Copy link

jasnell commented Dec 17, 2018

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

@NarHakobyan

This comment has been minimized.

Copy link

NarHakobyan commented Dec 17, 2018

Would be nice to have promise cancelation

@Mouvedia

This comment has been minimized.

Copy link

Mouvedia commented Dec 17, 2018

uuid?

@Mouvedia

This comment has been minimized.

Copy link

Mouvedia commented Dec 17, 2018

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

@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Dec 17, 2018

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

@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Dec 17, 2018

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

@Mouvedia

This comment has been minimized.

Copy link

Mouvedia commented Dec 17, 2018

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

This comment has been minimized.

Copy link

Mouvedia commented Dec 17, 2018

@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

This comment has been minimized.

Copy link
Member Author

littledan commented Dec 17, 2018

@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

This comment has been minimized.

Copy link

Mouvedia commented Dec 17, 2018

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)

@JonForest

This comment has been minimized.

Copy link

JonForest commented Dec 17, 2018

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.

@decadecity

This comment has been minimized.

Copy link

decadecity commented Dec 18, 2018

My two longstanding bugbears with the JS standard library (going back to my pre-jQuery days) are:

  1. A better interface for dealing with cookies (i.e. doesn't involve directly manipulating a string - something like Web Storage).
  2. 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.

@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Dec 18, 2018

@decadecity I'm wondering if the solutions at the web level, currently shipping in browsers, are enough for your use case.

  1. Does Web Storage solve the issue for you, or are there remaining problems?
  2. Does the WHATWG URL API solve this issue for you?
@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Dec 18, 2018

@JonForest Have you see the optional chaining proposal? It's attempting to add that operator.

@decadecity

This comment has been minimized.

Copy link

decadecity commented Dec 18, 2018

@littledan

  1. Web Storage is fine for client side storage but doesn't do cookies 😛 Directly manipulating the document.cookies string is a terrible API, I'd like to see something like the extension cookies API.
  2. The URL API looks like it's about right, thanks 👍
@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Dec 18, 2018

@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.

@anotheredward

This comment has been minimized.

Copy link

anotheredward commented Dec 18, 2018

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

@Mouvedia Mouvedia referenced this issue Dec 18, 2018

Merged

Document scope #32

@bakkot bakkot referenced this issue Dec 19, 2018

Closed

Comprehensions #31

@StoneCypher

This comment has been minimized.

Copy link

StoneCypher commented Dec 19, 2018

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

@StoneCypher

This comment has been minimized.

Copy link

StoneCypher commented Dec 19, 2018

I'll copy pasta a bunch right now if someone tells me where to put them

@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Dec 19, 2018

@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?

@martinheidegger

This comment has been minimized.

Copy link

martinheidegger commented Dec 19, 2018

Somehow I feel like the input from @kgryte could be useful to this discussion ;)

@StoneCypher

This comment has been minimized.

Copy link

StoneCypher commented Dec 19, 2018

Would be really nice if there was an official place to give people recommendations for a more complete standard libary

@gynet

This comment has been minimized.

Copy link

gynet commented Jan 3, 2019

Trees support is definitely one thing we want!

@chicoxyzzy

This comment has been minimized.

Copy link

chicoxyzzy commented Jan 9, 2019

  • exposed SameValueSameValueZero comparison algorithm
  • fixed Sets/Maps which values/keys compared using SameValue
@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Jan 10, 2019

Object.is?

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Jan 10, 2019

It wouldn't be web compatible to "fix" Sets and Maps to differentiate positive and negative zero, but with the rekey proposal, you'd be able to make your own Map and Set instances that did this differentiation.

@chicoxyzzy

This comment has been minimized.

Copy link

chicoxyzzy commented Jan 10, 2019

@littledan sorry I meant SameValueZero

@chicoxyzzy

This comment has been minimized.

Copy link

chicoxyzzy commented Jan 10, 2019

It wouldn't be web compatible to "fix" Sets and Maps to differentiate positive and negative zero

@ljharb yes, but it's probably possible to add new fixed versions of Set and Map to stdlib

@chicoxyzzy

This comment has been minimized.

Copy link

chicoxyzzy commented Jan 10, 2019

Also it would be web compatible to have old broken Set and Map available globally and new fixed Set and Map available via protected namespace

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Jan 10, 2019

It would; but I think it would be very confusing to have two things named "Map" that behaved differently.

@Mouvedia

This comment has been minimized.

Copy link

Mouvedia commented Jan 10, 2019

but I think it would be very confusing to have two things named "Map" that behaved differently.

Number.isNaN vs isNaN comes to mind.

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Jan 10, 2019

Indeed, a good example to avoid repeating :-)

@js-choi

This comment has been minimized.

Copy link

js-choi commented Jan 10, 2019

Indeed, Map and Array.prototype.map also come to mind too.

@Mouvedia

This comment has been minimized.

Copy link

Mouvedia commented Jan 10, 2019

Here's a summary of the most popular proposals based on the 👍:

  • a bunch of new methods for existing data structures
  • new data structures
  • a module based on RFC4122
  • a range generator
  • the tryptic Maybe/Just/Nothing
@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Jan 10, 2019

Good summary, those all seem like good ideas (though I'm skeptical of the last one).

@Mouvedia

This comment has been minimized.

Copy link

Mouvedia commented Jan 10, 2019

though I'm skeptical of the last one

If partial application ever reaches stage 4, you will have to bow down to our new functional overlords.

@ljharb

This comment has been minimized.

Copy link
Member

ljharb commented Jan 10, 2019

Certainly a Result would work very well in Promise.allSettled, and in the proposed Set/Map find methods, and a number of other places.

@evanplaice

This comment has been minimized.

Copy link

evanplaice commented Jan 16, 2019

I kinda wish Promises never happened in JS core. They're eager evaluated and miss valuable use cases (ex async vs waterfall vs parallel) that some of the more popular Promise libs (ex bluebird, async.js) provide out of the box.

I like the idea of Futures as a 'do over' to provide a more useful alternative to promises.

  • make it compatible with async/await
  • make it lazy loaded so it's possible to compose futures in a functional manner
  • add missing common functionality (ex async, waterfall, parallel)
  • make it so the API doesn't assume implicit knowledge (ex Promise.all 👎)
  • make it compatible with the proposed pipeline operator (ie and other related proposals)
@jbreckmckye

This comment has been minimized.

Copy link

jbreckmckye commented Jan 16, 2019

I just want monads. I don't care which, what they do or how they work. They can be Futures or they can be Maybes or they can be Eithers or they can be Readers or they can be Triads or who the hell cares. I Just. Want. More. Monads.

Oh. And add a range function whilst you're at it.

@Jack-Works

This comment has been minimized.

Copy link

Jack-Works commented Jan 18, 2019

Hello, for anyone who wants a range in JS, here is an independent proposal about range https://github.com/Jack-Works/proposal-Number.range

@Mouvedia

This comment has been minimized.

Copy link

Mouvedia commented Jan 18, 2019

If you are adding a static method for numbers then Id expect the analogue on String to generate range of characters:

/* String.range(range: String, charset = 'UTF-8': String): String */

String.range('∏-»', 'machintosh'); // ∏π∫ªºΩæø¿¡¬√ƒ≈∆«»
String.range('Ø-é', 'ISO-8859-1'); // ØÙÚÛÜÝÞßàáâãäåæçèé
@Jack-Works

This comment has been minimized.

Copy link

Jack-Works commented Jan 18, 2019

If you are adding a static method for numbers then Id expect the analogue on String to generate range of characters:

/* String.range(range: String, charset = 'UTF-8': String): String */

String.range('∏-»', 'machintosh'); // ∏π∫ªºΩæø¿¡¬√ƒ≈∆«»
String.range('Ø-é', 'ISO-8859-1'); // ØÙÚÛÜÝÞßàáâãäåæçèé

The range for String is not in the goals of Number.range, you can build your own proposal, I'll focus on numbers and BigInts only 😉

@Mouvedia

This comment has been minimized.

Copy link

Mouvedia commented Jan 18, 2019

I was using the generic you i.e. I wasn't talking to you :)
What I meant is that a generic range module would have to support characters and numbers.

@obedm503

This comment has been minimized.

Copy link

obedm503 commented Jan 18, 2019

@Mouvedia
This might be derailing the conversation, but what is the purpose/use case of a string range generator?

@Mouvedia

This comment has been minimized.

@kaizhu256

This comment has been minimized.

Copy link

kaizhu256 commented Jan 26, 2019

Trees support is definitely one thing we want!

a builtin sqlite3 (like python) would be far more practical and useful in web-applications than a low-level tree-library.

@kaizhu256

This comment has been minimized.

Copy link

kaizhu256 commented Jan 26, 2019

i don't know how it would be implemented, but some sort of full-text-search primitives would greatly benefit the industry.

@evanplaice

This comment has been minimized.

Copy link

evanplaice commented Jan 26, 2019

@kaizhu256 a builtin sqlite3 (like python) would be far more practical and useful in web-applications than a low-level tree-library.

Local storage can be used for quickly/easily persisting smaller amounts of data. Also, keep in mind that this would be for JS as a whole; so probably needs to be useful in bith the browser and node.

@kaizhu256

This comment has been minimized.

Copy link

kaizhu256 commented Jan 27, 2019

i may be wrong but i think what industry really wants is a "standardized" sqlite3 in browser with full-text-search capabilities (ala websql, which never seems to have truly died [1]). indexeddb is just terrible in terms of practical usability/performance (joins need to be done in userland-javascript? really?).

adding a low-level tree-library so users can reinvent even crappier versions of indexeddb is pointless.

i also don't mind a sqlite3-library to be memory-only, so it can be encapsulated for security reasons. one can always [infrequently] persist it to indexeddb as a blob.

speaking of indexedb, its sorely in need of an appendFile feature. without it, popular browser-db's like nedb are impractical for persisting largish datasets (> 20mb) [2].

[1] current websql browser-support
https://caniuse.com/#search=websql

[2] nedb emulates appendFile by re-saving its entire database as a blob to indexedb whenever a row insert/delete/update is performed.
https://github.com/louischatriot/nedb/blob/v1.6.0/browser-version/browser-specific/lib/storage.js#L49

@littledan

This comment has been minimized.

Copy link
Member Author

littledan commented Jan 27, 2019

I'd recommend making feature requests for IndexedDB in their GitHub repository; you're not likely to reach the right folks here.

@Mouvedia

This comment has been minimized.

Copy link

Mouvedia commented Feb 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment