1. 55
  1.  

  2. 16

    This is exactly the reason I kinda hate Node projects. I watched grimly as no less than four versions of lodash/underscore were pulled in during a project install.

    People, learn your damn standard libraries.

    1. 1

      haha I just wrote an internal post called “Lodash Functions We Probably Shouldn’t Use” for exactly this reason

    2. 9

      This is good advice. In addition better tools can help reduce the burden on the programmer. The lisp and smalltalk tool sets often include “tree shakers”. Dart has one. The google closure compiler provides something like this for javascript.

      Tree shaking amounts to whole-program analysis prove certain code is never going to be called and removing it from the delivered artifact. During development, don’t bother. But a production build performs the tree shaking.

      1. 3

        The google closure compiler provides something like this for javascript.

        Also Rollup and Webpack 2 for non-Java tools. :-)

      2. 9

        Interesting to see voices in the Ruby community starting to push for simple over easy.

        1. [Comment removed by author]

          1. 3

            or worse! ;)

        2. 13

          Part of your job as a library author is to treat your user and their application with respect

          “Job” you say?

          Counter-proposal: As a library author maintaining a project in your unpaid spare time, do whatever you damn well please to make your life easier. If a commercial entity is desperately upset that the product they got for free and are making money through using is adding 10MB to their runtime footprint, they’re welcome to spend some time or money getting a patch in to fix this.

          I mean, this isn’t bad advice. I actually mostly follow it myself (my primary project, Hypothesis, has zero external dependencies except for standard library backports), but asking people to do even more free work than they’re already doing so that the people making money off said free work have a slightly easier time of it really grinds my gears.

          1. 6

            Meh. 10mb of ram. Who cares? Evidently not many people, because anyone who cared would have profiled their memory usage and found the culprit pretty easily.

            Work with the tools that you have. Pruning your dependencies is one of those things like reformatting all your code according to a style guide - occasionally valuable, but often a disproportionate use of programmer effort.

            1. 5

              Code reuse is as bad as rewriting everything yourself…

              1. 4

                I’d say use external dependencies liberally in development; look at getting rid of them during refactoring phases. it may or may not ultimately make sense to include an entire library for one function, but being able to use that function rather than having to write it yourself while developing your code is a valuable thing.

                1. 3

                  I think a lot of this is failure on package management as well. These languages encourage using non-system libraries by making it trivial to add chains of external packages, encouraging waste.

                  1. 1

                    There are also other issues with dependencies:

                    1. It might become abandoned forcing you to maintain or replace it.
                    2. It can affect your design and make it more difficult to change.
                    3. It can handle 80% of use cases but 20% still need custom code. You’ll probably discover these 20% after you’ve added the dependency.
                    4. It can make code navigation more difficult.
                    5. It can expose you to legal risk: imagine a deep dependency (like mime-types from the article) to change license to GPL. Suddenly all your code is GPL-licensed! Patents can also play a role.

                    All in all, pulling in a dependency means putting a lot of trust in its maintainers. How many projects are worth trusting that much? Not many, I believe.