5 ms·

I hope (and expect) that there will be larger libraries that implement the functionality of a lot of very small packages. JavaScript really needs a comprehensiv

I hope (and expect) that there will be larger libraries that implement the functionality of a lot of very small packages. JavaScript really needs a comprehensive standard library.

dan-robertson 7y ago
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.
- Ididntdothis 7y ago
  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.
  - lmm 7y ago
    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.
    - Ididntdothis 7y ago
      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.
      - lmm 7y ago
        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.
        Ididntdothis 7y ago
        .NET doesn’t have that problem or C
        lmm 7y ago
        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.
        no_wizard 7y ago
        .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.
- BlewisJS 7y ago
  I made a repository to track what I consider to be the best Node libraries: https://github.com/blewisio/hqm 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.
- enneff 7y ago
  Why would you want the libraries you depend on to change??
  - krainboltgreene 7y ago
    The world changes, my friend.
  - zentiggr 7y ago
    They have bugs, and fixing them is good? They have better implementations, eventually, and improving performance is good?
thrower123 7y ago
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.
- other_herbert 7y ago
  Show us this, "the wheel"
  - other_herbert 7y ago
    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
- whostolemyhat 7y ago
  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.
  - fhennig 7y ago
    If there is a set of standard libraries, wouldn't they be cached in the browser anyways?
  - filleduchaos 7y ago
    > 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.
dillonmckay 7y ago
Like underscore or jQuery?

I hope (and expect) that there will be larger libraries that implement the functionality of a lot of very small packages. JavaScript really needs a comprehensive standard library.

dan-robertson 7y ago

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.

Ididntdothis 7y ago
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.
- lmm 7y ago
  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.
  - Ididntdothis 7y ago
    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.
    - lmm 7y ago
      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.
      - Ididntdothis 7y ago
        .NET doesn’t have that problem or C
        lmm 7y ago
        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.
        no_wizard 7y ago
        .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.
BlewisJS 7y ago
I made a repository to track what I consider to be the best Node libraries: https://github.com/blewisio/hqm 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.
enneff 7y ago
Why would you want the libraries you depend on to change??
- krainboltgreene 7y ago
  The world changes, my friend.
- zentiggr 7y ago
  They have bugs, and fixing them is good? They have better implementations, eventually, and improving performance is good?

thrower123 7y ago

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.

other_herbert 7y ago
Show us this, "the wheel"
- other_herbert 7y ago
  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
whostolemyhat 7y ago
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.
- fhennig 7y ago
  If there is a set of standard libraries, wouldn't they be cached in the browser anyways?
- filleduchaos 7y ago
  > 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.

dillonmckay 7y ago

Like underscore or jQuery?