1. 5
  1.  

  2. 3

    Mostly because then I have to conduct at least some degree of misplaced paranoia analysis, and verify whether any of my hand-picked, jack-ass dependencies just happen to phone home, insert tracking pixels and analytics references, undesirable attribution information, assorted decorative logos and watermarks, or randomly announce zero day vulnerabilities, causing a mad scramble to deploy security updates.

    1. 2

      Often when I use a dependency I try and split out what I actually need, often this process makes me disgusted with the quality of the library and It turns into a hard fork. The rest of the time the library is better than I expected and feel the original author did a better job than I would have and am happy to integrate it.

      It takes work to tell which is which though…

      1. 1

        These disadvantages of third-party code seem pretty weak. If you really aren’t making much use of the third-party library, then it won’t be a problem to replace it - but in that case there’s no reason to be afraid that the third-party code will hold you back from upgrading, because you can always replace it if and when you need to. Why make extra work for yourself by solving that problem now when it will probably never happen?

        1. 3

          It’s work to understand, validate, and keep dependencies up to date. For big chunks of complex code, that work can be justified. For small ones, it’s​far easier to just write it yourself.

          1. 1

            Sometimes the added friction can be frustrating

            We use a decent amount of Django libraries, and every version update requires us waiting for a couple months for dependencies to upgrade (or for us to send in patches to libs and the like).

            The main issue is that I pull in a dependency for a little thing, and then over time more people use the dependency, and suddenly the small usage becomes a pretty big usage. But if I had hand-rolled some code for the little thing, then we could deal with that.

            A lot of libraries are also extremely general, so even if you’re using a small set of it, compatibility ultimately depends on all the features the libraries use.

            I’ve found that this is more of an issue with things hooking into Django/Rails than for “pure” libraries, because the latter doesn’t have to deal with the business problem + hooking into a moving target that is the frameworks.

            1. 1

              The main issue is that I pull in a dependency for a little thing, and then over time more people use the dependency, and suddenly the small usage becomes a pretty big usage. But if I had hand-rolled some code for the little thing, then we could deal with that.

              But surely to whatever extent you’re using the dependency, you’re getting that much usage out of the dependency, no? If you’re using the dependency extensively such that you would have to write a lot of hand-written code to replace it, surely by the same token you’re getting a lot of value out of the dependency.

              A lot of libraries are also extremely general, so even if you’re using a small set of it, compatibility ultimately depends on all the features the libraries use.

              Yes and no - particularly in a dynamic language, surely you only care about the compatibility of the parts you’re actually using?

              1. 2

                In our experience the opposite is true.

                In a static language you can know you’ve found all usage sites because of a compile process or the like. In the dynamic languages we tend to have a lingering feeling that we’re forgetting some part of the usage somewhere.

                A good coping technique we’ve found is to not use third party libs directly, but write application-specific wrappers on the functionality. That way the third party dependency can be found in just one spot

                (this gets harder in application-wide usage of certain things though)

                To be clear: we still pull in dependencies all the time, and are mostly fine. But there’s always a couple that mess with us

            1. 1

              One wonders why the author doesn’t just update their version of Ruby. If they have dependencies, they would be better spent spending those cycles submitting upstream patches than leaving weird hacks in place to ambush the next poor bastard to have to maintain the codebase.

              You know what else offers similar features to Polyfill? The latest version of Ruby.

              1. 5

                He’s building a library and wanted that library to support Ruby 1.9, not just 2.0+.

                1. 2

                  I probably wasn’t explicit enough in the article but it’s not uncommon to have a situation where just updating Ruby isn’t that simple.

                2. -1

                  Yes, you plan to build a great castle ? Why make it out of rock, iron and wood while you could make it out of pre-made walls, made of building blocks, made of lego blocks, made of polymers ?

                  Much easier !

                  Now we just need that Castle factory factory to get started. And where’s my hammer, by the way. ;-)

                  1. 3

                    Preformed walls is exactly how modern fortifications are built (eg US forces in Iraq).