Should you include yet another dependency, or should you just write that code yourself? The latter might take more time, but it usually pays off.
Sharing code over the internet is probably the biggest revolution in software development. Need a login system? Just
gem install devise. How about payments? You can just
npm install --save stripe and start taking credit cards. All you need to worry about is the plumbing, and let someone else handle the nitty gritty details.
By not reinventing the wheel or building your own interface to an API, your project can go from zero to sixty in a matter of hours. Without package repositories, hackathons in their current form probably wouldn't be possible.
Unfortunately, the power of standing on the shoulders of giants tends to go to people's heads. Using existing code can make a lot of sense for cumbersome processes like authentication, DOM rendering, testing, etc. Those are broad concepts that can be complicated and usually don't warrant an overly custom solution. But does using existing code make sense for concepts of smaller scope? Quite often, it doesn't. Yet so many developers import 3rd party code willy-nilly so they can get their jobs done faster.
All the extra dependency incurred by using 3rd party code is commonly treated as minor "technical debt" that can be easily handled later, but this always turns into kicking the can down the road.
A lot of developers believe they are glorified plumbers, and they are correct. They don't have to be plumbers, though. If they can choose to write more of their own code and exhibit more discretion when importing someone else's code, they will not only no longer feel better about themselves in their jobs but end up with higher quality projects.
Just because something is popular doesn't mean that it's good, thus a 3rd party software isn't better than custom code because lots of people use it.
When you use someone else's software, you are almost always saving time in the short term. This can be a good thing, especially when your team is small and you really need prototypes to decide on course-corrections. If you never play the long game, however, you can end up with a bad codebase that will slow you down.
Unlike code that you have 100% control over, 3rd party code is subject to change at the whim of someone you have little or n sway over.
Sure, you can lock your packages to specific versions, but if what if you want to use the latest version of something and the API for that something has changed in a breaking way? Now you have new work on your hands, and not fun work at that.
As dependencies often depend on other dependencies, you might find yourself forced to resolve problems during package updates, lest you want your codebase to hold you back from using the latest and greatest stuff.
A 3rd party software isn't better than custom code because lots of people use it.
Even if you don't need new features, you may still be compelled to update your packages and incur breaking changes because the versions of packages you were using have minor bugs or, worse, security issues. You do have a choice here, but I don't recommend being a fool and ignoring these problems for the sake of expedience. Surely, you want to feel good about yourself?
You will inevitably pay, in some way, for relying on other people's code. I've seen it in every codebase I've worked on. No matter where I've worked, software I've worked on has outdated packages that cause deprecation and security warnings, and changes of all sizes can be slow to make because 3rd party code either doesn't do what's required or is broken with current generations of other packages.
This is why I advocate opting to write code before using someone else's. Most problems in programming aren't actually that hard, but do consume some time to implement and test. That's time well spent, however, because it means you'll be able to make changes to your project more easily when your code is purpose-driven rather than generalized, as is the case with most 3rd party software.
Time will be saved in the long term because you are not dependent on other organizations whom you have no control over. You won't have to worry so much about someone in another part of the world arbitrarily deprecating functions or interfaces because of reasons. If you always consider design patterns, your code will be easier to reason about because it'll be simpler and use fewer black boxes.
This doesn't mean that you shouldn't use other people's code at all; in fact, it's an excellent idea to look at how a software package works and replicate that functionality in your own codebase while simplifying it and removing all the parts that you don't actually need. Simpler code that you have to write is preferable to complicated code that someone else writes.