4 ms·
Introducing a towering pile of dependencies is _introducing_ a business problem; there is a cost of ownership to a dependency tree that only grows as it grows.
by frio 4y ago
Introducing a towering pile of dependencies is _introducing_ a business problem; there is a cost of ownership to a dependency tree that only grows as it grows.
Grabbing a library from somewhere and saying "problem solved, onto the next one" isn't a sustainable development practice; there has to be some assessment of "is this library popular/the maintainer trustworthy/what risk do we carry if it gets abandoned/will someone pick it up/_does it solve a big enough problem to warrant the effort_" that goes with every choice to pick one. Further, every single 3rd party dependency carries security risks, and every time you add one, you make it more likely one of them will get compromised.
I used to be a "just grab the libraries and move on" guy, but we're currently working on getting $currentEmployer off some old major versions of React, CRA and Spring Boot because a previous developer was of the same mindset and half the stuff he grabbed has died and isn't forwards compatible. It's not a fun process, and many problems the libraries solve could've been solved in-house for less total effort.