In defense of leftpad
Given the time I’ve had to think about the whole leftpad controversy, I have to come to the conclusion that leftpad was PERFECTLY FINE with its decision to build a module with only eleven lines. (As to the brooha over unpublishing and then being forcibly republished by npm, that is a different topic.)
leftpad wrote code anyone with half a brain should be able to write
That must be the biggest sentiment I’ve heard. Blogs, podcasts, and other forums have thrown out this strong criticism of leftpad’s code. It’s best summarized as “have people forgotten how to code?”
Gee, leftpad getting unpublished broke React.js, Babel.js, and how many other systems? If those impressive projects saw value in leftpad, sounds pretty big of me to judge them all for making such a foolish decision. After all, that’s what I’m doing, right? I’m ascribing judgment for using it.
Let me be clear: I haven’t actually READ leftpad’s code. I’m not defending the physical lines of code in that module. The market spoke and accepted leftpad. I am defending the choice others made because I myself haven’t invested the time to make a better choice.
leftpad wasn’t REALLY used by React.js, etc. It was just a transitive dependency
This one doesn’t sit right. It’s kind of like saying, “React.js is good. The people writing it would never need something like leftpad. They just got caught by some intermediate dependency.” Can you smell the disdain?
If leftpad was used by an intermedia dependency, and that is what all the big weights used, then the transitive property applies. Not only has the market said leftpad met needs, but the intermediate dependencies are just as valuable. See what I did there? Transitive dependency, transitive value.
leftpad isn’t actually the best way to do what it did
Here is where it gets interesting. This is what I hear from those that have spotted the transitive link. Can’t criticize React.js, because they didn’t REALLY use leftpad. Let’s look elsewhere.
People have been singing the UNIX tune of “do one thing and do it well” as microservices arise. Defenders of leftpad point it out as a composable function, adhering to the UNIX philosophy. But if you can tear out “do it well”, then leftpad doesn’t qualify for this concept. Hence, leftpad was a badly written composable function.
Sorry, maties, but as software engineers, we seek out solutions on a daily basis. And in the land of open source, we constantly make “build or buy” decisions. Whenever someone asked me, “what is an engineer”, my answer has always been, “we find a good enough solution for the problem at hand.” We don’t seek perfect answers, because we don’t have an infinite budget.
For a LOT of people, leftpad was good enough. They could have written a better solution, but they could also have written a better solution for LOTS of other modules. Imagine the cost of perfecting every single thing you use. Or how about this: imagine the cost of tens of thousands of developers writing an equivalent to leftpad. Perhaps 15 minutes tops, but multiplied by 10,000 and your talking 2500 hours of effort. Doesn’t that defy the concept of open source?
I know people that don’t like certain tools out there. They have written their own version of things. At first glance, there’s underscore and lodash. These two libraries essentially do the same thing. But one project was not satisfied with the other project. Hence, they built a fork and whole community around it.
I can spend all my time building everything from scratch and live under the haughty label “I know how to program. I’ll build it myself.” But we already have a term for developers like that: “Not Invented Here“. Some people will only touch code they themselves wrote.
If you actually spent the time to read leftpad’s code, then used it or decided otherwise, that’s fine. But don’t go around criticizing others for using leftpad. After all, you’re criticizing the choices of MANY others.