There's nothing wrong with leftpad as a library concept. The problem was that it got hacked, not that it does something useless that everyone should write on their own.
leftpad was incorporated into ECMAScript in 2017 for a reason.
> Outsourcing of complexity is /not/ elimination of complexity.
This is technically true but functionally false. You're literally arguing against the concept of abstraction layers, while writing text into a form built on top of hundreds of them.
There are two thoughts I have regarding this:
1) Leaky Abstractions seems like what you're trying to point out, and accurately so [0] but,
2) you can still rely on even leaky abstractions. You must, in fact, to function in this world. In some ways the quote, "In preparing for battle I have always found that plans are useless but planning is indispensable" [1] applies to abstraction as well.
> You're literally arguing against the concept of abstraction layers, while writing text into a form built on top of hundreds of them.
Sorry, I see how what I said could have been interpreted this way. That's /definitely/ not my intent, and I'd like to clarify.
I am arguing that abstraction layers have cost, and (independently) that third-party dependencies have cost. (Abstraction layers are a great tool for isolating third-party dependencies, so they tend to go together, but they're independent things here.)
Also, lack of abstraction layers has cost, and building everything in house has cost.
These costs need to be traded. In some cases, leaning on external dependencies is the right choice. In other cases, it's not.
If complexity (opposite of simplicity) under an abstraction layer is neglected (estimated at zero), using simplicity as a guideline for making engineering decisions will lead you to the wrong decision some of the time. Similarly, if complexity under an abstraction layer is treated as just as non-simple as complexity above the abstraction layer, using simplicity as a guideline will lead you to the wrong decision some of the time.
Therefore, "the simplest thing that can possibly work" is too naïve a metric to be used for making decisions (as opposed to just for justifying decisions you already want to make). It takes a more nuanced discussion of types of simplicity, and whether complexity is being eliminated or just hidden, and if it's hidden how likely it is to stay hidden, to make this rule useful.
For the record: I buy my bagels from a store. When the roads are closed due to snow, I don't have a bagel. That's the right decision for me, unsurprisingly, for this problem.
Finally, I'll argue that there /was/ a problem with leftpad as a library concept. There is an inherent minimum complexity to a dynamically linked external dependency. The reduction in complexity of the implementation must be at least as large as this cost. One can argue about where the line lies (and it depends on the maturity of your ecosystem, etc), but I'd take the stance that leftpad is too simple to implement directly for pushing it to an external dependency to ever e the right choice.
If your point is, "abstractions don't have zero cost" point taken. But if your point is, "abstractions have meaningful cost", I'd rephrase that as, "The better an abstraction is, the closer to zero its cost becomes."
Irrelevant point of order: leftpad didn't get hacked, the owner took it down to prove a point and broke every package that depended on it as npm allowed packages to just be completely removed by the authors at that time.
leftpad was incorporated into ECMAScript in 2017 for a reason.
> Outsourcing of complexity is /not/ elimination of complexity.
This is technically true but functionally false. You're literally arguing against the concept of abstraction layers, while writing text into a form built on top of hundreds of them.
There are two thoughts I have regarding this:
1) Leaky Abstractions seems like what you're trying to point out, and accurately so [0] but,
2) you can still rely on even leaky abstractions. You must, in fact, to function in this world. In some ways the quote, "In preparing for battle I have always found that plans are useless but planning is indispensable" [1] applies to abstraction as well.
[0] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
[1] https://quoteinvestigator.com/2017/11/18/planning/