Consider the Following
Let us consider a feature that is quite common among sites: Sticky content. For those that may not know what I am referring to, sticky content is content that becomes fixed at a specific point. Typically when a user a scrolling down a page and the top of the browser reaches your element, your element becomes fixed to prevent it from disappearing as you scroll.
Consider this library, which can be used to achieve sticky functionality for your element. The library has over 150 lines of code for something that can be achieved in less than 20…I am making an assumption that the library can be easily implemented into your application without any problems. That itself can be its own world of headaches.
It is not uncommon that at some point features may be requested which are not available out of the box with that module. What do you do now? Do you now write your own library or do you attempt to extend the one you are using? That may not be an easy call to make depending on the situation. One thing that is for certain, which is if you go the route of extending the existing module, it will be a nightmare. Not only will you have to spend time looking into how it works, but you will have to make sure your extended functionality does not break what is already there.
With that code, should there ever be a need for extended functionality, it would be a breeze extending it not only for the person who wrote the initial logic, but also for any other developer that might possibly work on the project. The code was short enough that it does exactly what it needs to, without all the extra unnecessary bells and whistles making it more complicated and bloated than it has to be.
I see this trend among developers more and more. They prefer to save themselves time by going with someone else’s library (even for the simplest of tasks). At the end of the day, if you are a developer you should be relying on your own skills to do what needs to be done and when possible, avoid the bloat and headaches of pre-made libraries.