3 ms·

On the other side of the spectrum, you have large Java libraries where you need to somehow figure out which 20 classes collaborate to do a task, and the "docume

• MichaelGG 12y ago
  That's the lack of design of a library, not really necessarily the size. You could easily have one entry point class with a bunch of ready to use functions and start your docs off there. Otherwise, you're just punting the discovery problem up a level. There's also a benefit in having multiple things in a module. You could make your code generic over the type of hash being used for instance. As far as node, you could easily export 20 different hash functions for use, instead of a dedicated sha1 package. Then getting yet another when you want hmac. The downside is nontrivial. In a repeatable build environment it can add tens of minutes of delays to a build as these tens of thousands of files aren't free. (And that was on a VM by one of the big providers, with top notch bandwidth.) Just even doing a local copy of so many files can take a while.
  • insaneirish 12y ago
    > In a repeatable build environment it can add tens of minutes of delays to a build as these tens of thousands of files aren't free. (And that was on a VM by one of the big providers, with top notch bandwidth.) Why would you be pulling modules in from an Internet based repo on every build? > Just even doing a local copy of so many files can take a while. That means your cloud provider has poor file I/O performance, which is not unusual.