On the other hand it tends to be harder to change things in a standard library (ie that is where good code goes to die) for want of not breaking dependencies.

If all libraries are tiny then a set of “the best” libraries can evolve over time through the preferences of individual people.

Obviously this doesn’t work so well for finding libraries or having them work great together.

Most languages have standard libraries and things are fine that way. Most NPM modules have a scope that’s too small. Instead of 100 string modules they should get merged into one string library.

Large standard libraries are a major pain for evolving the language and the libraries in question. (E.g. Python's standard library is notorious as "where modules go to die"). Putting each piece into its own library is great as long as your tooling can manage them effectively.

What could be useful is some concept of a "metalibrary" or "platform", a la the "rust platform" and "haskell platform" efforts - a sensible aggregate of libraries with compatible versions that work together and cover most of the common things you need - not as an inflexible monolith that you have to do big-bang upgrades of, but as a starting point that you can then customize as needed. Almost like a Linux distribution. But keeping the ability to upgrade one small piece without touching the others is really important.

Things like string manipulation, array manipulation or similar are pretty well understood and could be put into a comprehensive library. On the few more projects I have seen there were some trivial packages like “isodd” or something like this which then recursively pulled in dozens of other trivial stuff. This just doesn’t seem to be a problem in other languages.

Major upgrade problems because of supposedly simple, well-understood library matters like string manipulation or array manipulations are definitely a problem that other languages have - just look at the whole Python 3 saga.

.NET doesn’t have that problem or C

C doesn't have even basic string operations in its standard library. It could do with a lot more libraries but is hampered by not having any kind of dependency management tooling. Where there are monolithic libraries, upgrading is absolutely a problem, but a lot of functionality in C is just not there, which ends up with a lot of duplicated code, snippets copied and pasted or simply reimplemented in every project, and all the associated maintainability and security problems.

.net I'm less familiar with, but I've certainly heard of projects being stuck on older versions of it, and again for a lot of tasks it tends to be a case of there just not being a library available at all.

.NET suffered from the fact that you couldn't move easily between versions. This changed with .NET Core, where you can target (and install multiple versions of) different instances of the runtime/SDK.

That, combined with the ability to target .netstandard and a much more clear line of sight for what is compatiable with those standards, have made this, to me, a non issue.

It was historically though, very hard to deal with for large apps.

Again I'm not really part of that ecosystem, but it sounded to me like .net core/standard involved doing exactly what Ididntdothis was arguing against - moving functionality out of the language standard library and into separate libraries with their own independent versioning.

before I say more, I just want to clarify I meant no ill direction or intent your way. I genuinely think there is a fine balance to be struck between a good stdlib & just moving things into the broader module ecosystem for any language. Some get it more right than others (Go Lang, for instance, I think is cool, in that it has the stdlib, but if I understand it correctly the stdlib is maintained as separate installable libs)

Microsoft hasn't move much out of the core C#/.NET libaries, rather they made it easier to interop the SDKs/runtimes. The actual libaries themselves haven't changed much in respect to this issue.

The reason I don't believe it's a balance is simply that I haven't seen a downside. The world has drifted towards microlibraries largely because of real advantages, brought on by automated package management making them practical. People here seem to be grasping at straws to find a justification for disliking that change.

I made a repository to track what I consider to be the best Node libraries: https://github.com/blewisio/hqm. It's just a readme and directory (for now), but serves as a handy reference when trying to find a good library that does some particular task.

Why would you want the libraries you depend on to change??

They have bugs, and fixing them is good? They have better implementations, eventually, and improving performance is good?

The world changes, my friend.

I mean, we used to all just use jQuery and lodash. Then the cool kids decided that wasn't cool anymore, and every function should be a separate package.

I'm sure the wheel will come around again.

Show us this, "the wheel"

man tough crowd :)... I thought more of you would've gotten the Futurama reference ... Fear of a bot planet.. I think..

edit no, the one with the evolution of robots and such

That's because there's no point including an entire library if you only need a few functions. It means that your deployed bundle is much smaller, which means that users don't need to download unused code and waste time/bandwidth (ie a good thing).

Tree shaking still isn't that great or widely available, so separate packages mean you can do this manually.

> Tree shaking still isn't that great or widely available

This sounds like an opinion based on the state of web development a decade ago.

In 2020 on the other hand the Google Closure Compiler has been a mature project for years, and even projects not explicitly focused on dead code elimination (bundlers like Webpack and Rollup) do a decently thorough job of cutting out unnecessary code with the right plugins.

If there is a set of standard libraries, wouldn't they be cached in the browser anyways?

Like underscore or jQuery?