Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well from https://www.npmjs.com/browse/depended we can see a few candidates:

- request, indicates that the built-in networking isn't working for everybody

- moment, the JS nor Node have very comprehensive Date manipulation

- express, again indicates that the built in networking library isn't working for everyone

- fs-extra, literally filling the gaps in the built-in fs package

- async, bluebird, these could easily be considered "standard library" material



I don't know. While I commonly use several of these it feels like this easily bleeds into questions of subjective "taste" and domain-specific libraries.

If you're not changing anything else about the management of these packages, what's the advantage of having request or express as part of the "standard" library?

And if you are changing the management of these packages, then maybe that's the solution with or without expanding the core library?

I think that Java for example has similar defacto-but-not-actual "standard libraries" that correspond to many of these domains.

I'm not convinced that a larger "core" is addressing the root problem.


All standard libraries get conveniences such as these built upon them. That is not the role of a standard lib, which is to provide a basic level of OS compatibly and some commonly useful data structures and utilities. The cost of standardization is rigidity, so they are typically kept thin.

I happen to not like the design choices of many of those libraries you mentioned and choose to to use them.

Express is an entire web framework. What other ecosystems have you used which would ship with these sorts of libraries?


Go's built-in http package is roughly equivalent to Express




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: