If you have to depend on a external library for a simple function which can be written in a intro programming course, it's a red flag.
One of the big constraints we have in front end development is that every added feature adds to the bundle size of code we have to send down the wire to the end user.
When I worked in mobile app development third party libraries tended to be very large with many many features. Only a tiny fraction of that library ends up matching your use case. However when you build you end up bundling up the whole thing into your app.
JavaScript has more of a culture of many many small hyper focused packages. The logical conclusion being single function packages like left pad.
This has two benefits. One - you have less dead code in your final build. Two - if one of your dependencies is already using leftpad you essentially get to use it "for free".
If everyone did what you are suggesting you would find multiple instances of leftpad. One version you wrote. One version your dependency wrote. One version your dependency's dependency wrote etc.
Surely there have to be tools to process dependency libraries to strip out any unused code.
A good example: There is a library called Moment for handling dates. Due to the way the interface was built it basically can't be tree shaken. It's an excellent library but it's on the heavy side. For a while now people have been moving to libraries like Date-Fns which are collections of individual functions. This library can be tree shaken as it's obvious which functions you are using and which you are not
The problem is Invented Here syndrome and coddling. https://en.m.wikipedia.org/wiki/Invented_here
The reason this exists is due to a lack of leadership in the front end space. More specifically, a need to hire untrained entry level developers and deliberately not train them whether due to insecurity elsewhere and a complete inability to write documentation.
> If everyone did what you are suggesting you would find multiple instances of leftpad.
It was about 8 lines of code a child could write that you probably don’t need in the first place.
However if the threshold for not including a package is that it's 8 lines of code that would rule out using most of the functions in Lodash and Underscore.
If the threshold is not importing code a child could write that would rule out using Babel which was in fact literally written by a child.
> This has two benefits. One - you have less dead code in your final build. Two - if one of your dependencies is already using leftpad you essentially get to use it "for free".
This culture has really backfired in practice.
What we now have is a proliferation of packages which do the same thing. The problem is that it is less likely that your dependencies are going to be using the packages, even though desired functionality is the same. For example, if you have two dependencies which need to do HTML encoding, chances are that they choose different packages for that job. So now as an app developer you have to pay for both.
This combined with a culture which loves Semver but doesn't mind breaking backwards compatibility ("just update the major version!") gives a huge mix of packages which can't be fixed by tree shaking.
Go seems to have done a better job with a lot of utilities found in its standard library. But, it also has a mindset that it's better to just copy code than to add a dependency. Another factor there was of course that dependency management was a bit painful and fragmented until a few releases ago, unlike NodeJS which had NPM and its ecosystem not long after it came out.
I'm saying this as someone that hasn't used either.
Auditing is nearly impossible.
The complete lack of a standard stdlib means always relying on community packages.
Also, not a complaint directly against node directly, but for the ecosystem and developers. There is not a culture of compatibility, further fueled by the fact that multiple versions of the same dependency can be included in the same code base by different dependencies.
Coming from any other language were it is a goal to keep external dependencies down, nodejs is nightmare fuel.
After all, if I love Java but hate AbstractSingletonProxyFactoryBeans, I'm probably going to hate being a professional Java developer.
Some would see the left-pad incident not as an isolated oddity, but as representative of the entire NodeJS ecosystem - showing a weak standard library, a culture of pulling random, unaudited code from the internet, and rats-nest dependencies.
If your first thought is a library, whether you wrote it yourself or not, then you're doing JS badly.