While I agree it'd be nice for their to be unification, rather than a fragmented set of varying libraries, the one size fits all solution tends to be a maintenance nightmare. I guess we just have wildly different experiences, but mine is such that adding a third party dependency is typically a major liability and often originates from less experienced developers.
Adding a dependency is a burden. You don't have direct control over the evolution of that code. You have to keep track of the changes. If you're lucky, the library will have a changelog, but that's sorely lacking in most projects. Blindly upgrading will bite you, so if you have a product that can't suffer downtime, you really need audit that code for every upgrade. Good luck if you've determined that the version you have is sufficient, so you've locked it down, but then a security issue is found . . . winding back patches like that can be an exercise in futility. Oh, and then there's the wonderful world of transitive dependencies.
NIH for everything isn't ideal, naturally. But pushing everything out to 3rd party libs has its own set of problems that in many cases are worse. In my experience, a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain.
> a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain
Indeed, but this is hopefully obvious to all of us. My point is that the cost of maintenance is vastly higher than is ever really understood. Most code is written in the context of delivering a project, and here the highest cost is considered to be getting functional code out of the door (even the first set of bugs is often overlooked).
I'd propose the counterintuitive and unpopular view that the cost of development is the tiniest fraction of the lifecycle cost of lines of code when you factor in things like bugs, keeping up with security, adapting to environment changes, modifications due to new requirements, and probably most importantly the multiplying effect of adding new moving parts which makes each piece of code in a solution more expensive to write and maintain than the last.
I'm perfectly aware that this will seem ridiculous and in some ways it is a little aggressive to make the point, but as evidence I would consider how many work years are spent on libraries which contain a tiny part of the functionality that is contained in useful software.
Therefore the trade-off, while being about the right things, is very rarely correctly sized.
Adding a dependency is a burden. You don't have direct control over the evolution of that code. You have to keep track of the changes. If you're lucky, the library will have a changelog, but that's sorely lacking in most projects. Blindly upgrading will bite you, so if you have a product that can't suffer downtime, you really need audit that code for every upgrade. Good luck if you've determined that the version you have is sufficient, so you've locked it down, but then a security issue is found . . . winding back patches like that can be an exercise in futility. Oh, and then there's the wonderful world of transitive dependencies.
NIH for everything isn't ideal, naturally. But pushing everything out to 3rd party libs has its own set of problems that in many cases are worse. In my experience, a more experienced developer knows when to make the trade-off and solve the problem in-house with a much smaller body of code that's far easier to maintain.