6 ms·

> a myriad of tiny 10-line libraries with a spaghetti dependency graph. I'm curious why people dislike this. I'd rather have lots of little decoupled libraries

by evv 8y ago

> a myriad of tiny 10-line libraries with a spaghetti dependency graph. I'm curious why people dislike this. I'd rather have lots of little decoupled libraries than huge monolithic dependencies that attempt to do everything in one big folder. The big libraries often duplicate functionality found in smaller tools, and I would rather they simply consume a bunch of small tools that can be shared across the ecosystem. It reminds me of the oldschool pre-systemd UNIX philosophy of "do one thing, and do it well". Did everybody change their minds on this?

thaumasiotes 8y ago
The problems come in when one of your little dependencies itself depends on something else. You want a single level of dependencies. Monoliths are good for this because they try to be self-contained.
scrollaway 8y ago
There are some downsides to it. The most critical issue is the left-pad threat: A tiny, unknown dependency with 3 stars on Github ends up being part of a huge project. Nobody in JS audits every single dependency up the tree, because there are too many of them. So situations like what happened with left-pad absolutely can and will happen again. But there are other misc issues. For example, each package is a separate download with a bunch of metadata and overhead, so on download it spends a lot more time on those two lines than it would if they were just part of the library. I like code splitting and there's a lot of benefits to the approach JS is taking, but it's not without its faults.
DCoder 8y ago
The JS libraries usually fail at the "do it well" part. * UNIX tools don't get updated every week. * UNIX tools don't get deprecated and replaced every month. * When UNIX tools do update, the updates don't carry a risk of adding shady code from new maintainers because the original author "got bored lol" and handed the repo over to the first person who asked. * When UNIX tools do update, the updates don't introduce unvetted and undocumented code that will, for example, start displaying Christmas decorations in your UI on certain dates. How many UNIX tools actually come in "writing this from scratch is faster than searching for a tool that already does this, so I'll just write my own" size (except for `yes` and such)? Trick question: is trying to install a new UNIX tool similar to this [0]? [0]: https://what.thedailywtf.com/post/1441806 https://what.thedailywtf.com/post/1441806
- JdeBP 8y ago
  In counterpoint, just for fairness' sake, we have: The jokes in the Linux "man" command that indeed did trigger at a certain magic time. * https://unix.stackexchange.com/questions/405783/ https://unix.stackexchange.com/questions/405783/ The failure to take on board the improvements to Linux "ifconfig" from 2009. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359676#41 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359676#41 Changes to GNU "ls" that did not go unnoticed. * https://bugzilla.redhat.com/show_bug.cgi?id=1361694 https://bugzilla.redhat.com/show_bug.cgi?id=1361694
  - twic 8y ago
    That ls change is absolutely bizarre! One of the aspects of, ahem, bazaar-style development that we don't talk about much is that decisions get made by whoever can be bothered to turn up. If it so happens that the only people maintaining ls are the three people crazy enough to care about maintaining ls, then ls gets crazy decisions.
- ATsch 8y ago
  Another difference is that the unix tools are a bounded and known set of utilities that work independently and compose well together and try not to overlap in functionality. Meanwhile, js modules are an unbounded set of unknown modules that are intertwined and aren't designed to work together and overlap in functionality.
srean 8y ago
Interfaces should be simple but functionality behind that interface should be non-trivial, otherwise it is not a net value add. John Ousterhout speaks about this much better than I could.
diminoten 8y ago
People don't know how to handle libraries that update frequently because it requires more buy-in on a specific aspect of CI/CD that folks don't often invest in (admittedly because it's not immediately obvious).
JdeBP 8y ago
To talk about "monolithic" systems and "UNIX philosophy" is to not really understand. It's an oft-made mistake, even just considering systemd alone. * https://news.ycombinator.com/item?id=19024256 https://news.ycombinator.com/item?id=19024256 * https://news.ycombinator.com/item?id=13390245 https://news.ycombinator.com/item?id=13390245 The actual ideas in computing when it comes to modular systems are cohesion and coupling. Modular systems should have high cohesion and low coupling. The objection to leftpad levels of granularity is that it is high coupling, lots of little modules inevitably requiring one another in large numbers and complex ways. And a lack of any grouping at all is actually a lack of any sort of cohesion, coincidental or otherwise.
int_19h 8y ago
The definition of "one thing" can vary a lot. For example, libpng does one thing: it reads PNG images. But that's a much bigger thing than something like left-pad.
josephg 8y ago
I've worked on lots of nodejs projects with 1-2k transitive dependencies. I've seen plenty of simple projects end up with close to 1 gig of files in node_modules. And almost all of those files are never used at runtime. I'd be a lot happier with npm if tiny libraries took up less space on disk. Storing a local copy of each dependency's readme file, license file, package.json and test suite is overkill when the module itself is only a few lines long. Its also very common for sloppy package maintainers to accidentally ship binary files in their npm module (image banners for their readme.md, test data, etc.) Npm should only download the javascript file for small single-file modules. Nodejs itself already supports this - if you have a javascript file in your node_modules directory, require() will pull it in like normal. The license might need to be prepended to the file in a comment block, but this could easily be done automatically.

by evv 8y ago

thaumasiotes 8y ago

The problems come in when one of your little dependencies itself depends on something else. You want a single level of dependencies. Monoliths are good for this because they try to be self-contained.

scrollaway 8y ago

There are some downsides to it. The most critical issue is the left-pad threat: A tiny, unknown dependency with 3 stars on Github ends up being part of a huge project. Nobody in JS audits every single dependency up the tree, because there are too many of them. So situations like what happened with left-pad absolutely can and will happen again. But there are other misc issues. For example, each package is a separate download with a bunch of metadata and overhead, so on download it spends a lot more time on those two lines than it would if they were just part of the library. I like code splitting and there's a lot of benefits to the approach JS is taking, but it's not without its faults.

DCoder 8y ago

The JS libraries usually fail at the "do it well" part. * UNIX tools don't get updated every week. * UNIX tools don't get deprecated and replaced every month. * When UNIX tools do update, the updates don't carry a risk of adding shady code from new maintainers because the original author "got bored lol" and handed the repo over to the first person who asked. * When UNIX tools do update, the updates don't introduce unvetted and undocumented code that will, for example, start displaying Christmas decorations in your UI on certain dates. How many UNIX tools actually come in "writing this from scratch is faster than searching for a tool that already does this, so I'll just write my own" size (except for `yes` and such)? Trick question: is trying to install a new UNIX tool similar to this [0]? [0]: https://what.thedailywtf.com/post/1441806 https://what.thedailywtf.com/post/1441806

JdeBP 8y ago
In counterpoint, just for fairness' sake, we have: The jokes in the Linux "man" command that indeed did trigger at a certain magic time. * https://unix.stackexchange.com/questions/405783/ https://unix.stackexchange.com/questions/405783/ The failure to take on board the improvements to Linux "ifconfig" from 2009. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359676#41 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359676#41 Changes to GNU "ls" that did not go unnoticed. * https://bugzilla.redhat.com/show_bug.cgi?id=1361694 https://bugzilla.redhat.com/show_bug.cgi?id=1361694
- twic 8y ago
  That ls change is absolutely bizarre! One of the aspects of, ahem, bazaar-style development that we don't talk about much is that decisions get made by whoever can be bothered to turn up. If it so happens that the only people maintaining ls are the three people crazy enough to care about maintaining ls, then ls gets crazy decisions.
ATsch 8y ago
Another difference is that the unix tools are a bounded and known set of utilities that work independently and compose well together and try not to overlap in functionality. Meanwhile, js modules are an unbounded set of unknown modules that are intertwined and aren't designed to work together and overlap in functionality.

srean 8y ago

Interfaces should be simple but functionality behind that interface should be non-trivial, otherwise it is not a net value add. John Ousterhout speaks about this much better than I could.

diminoten 8y ago

People don't know how to handle libraries that update frequently because it requires more buy-in on a specific aspect of CI/CD that folks don't often invest in (admittedly because it's not immediately obvious).

JdeBP 8y ago

To talk about "monolithic" systems and "UNIX philosophy" is to not really understand. It's an oft-made mistake, even just considering systemd alone. * https://news.ycombinator.com/item?id=19024256 https://news.ycombinator.com/item?id=19024256 * https://news.ycombinator.com/item?id=13390245 https://news.ycombinator.com/item?id=13390245 The actual ideas in computing when it comes to modular systems are cohesion and coupling. Modular systems should have high cohesion and low coupling. The objection to leftpad levels of granularity is that it is high coupling, lots of little modules inevitably requiring one another in large numbers and complex ways. And a lack of any grouping at all is actually a lack of any sort of cohesion, coincidental or otherwise.

int_19h 8y ago

The definition of "one thing" can vary a lot. For example, libpng does one thing: it reads PNG images. But that's a much bigger thing than something like left-pad.

josephg 8y ago

I've worked on lots of nodejs projects with 1-2k transitive dependencies. I've seen plenty of simple projects end up with close to 1 gig of files in node_modules. And almost all of those files are never used at runtime. I'd be a lot happier with npm if tiny libraries took up less space on disk. Storing a local copy of each dependency's readme file, license file, package.json and test suite is overkill when the module itself is only a few lines long. Its also very common for sloppy package maintainers to accidentally ship binary files in their npm module (image banners for their readme.md, test data, etc.) Npm should only download the javascript file for small single-file modules. Nodejs itself already supports this - if you have a javascript file in your node_modules directory, require() will pull it in like normal. The license might need to be prepended to the file in a comment block, but this could easily be done automatically.