The points you make are important ones with regard to using library methods. The question then becomes: do we need a separate library/dependency/liability for every trivial function (even if trivial >> 10 sec)?
(for context, I approach this from the Java ecosystem, where a small number of almost-de-facto-standard libraries are available to serve most needs)
I think that javascript is unique for a couple of reasons. Unlike most languages, javascript has a minimal standard library, so a lot of functionality that you'd expect to be included with the language isn't present, so people turn to NPM.
Someone could conceivably create a package to include all the trivial functionality that is otherwise being included piecemeal, but this package would grow to be pretty big. Then we're including a bunch of functionality we don't necessarily need to get access to one or two functions.
Definitely not to start a (reverse) war of the languages, but the java standard library is wholy inadequate. Together with tree shaking on the one hand, and the fact that a typical webapp pipes a lot of javascript on the other, there is no technical or practical impediment to having bigger libraries.
I actually feel like Java's standard library has improved considerably, especially with Java 8.
Tree shaking would solve the issue of depending on a handful of functions from a large library, but tree shaking also requires some effort to set up and can be imprecise due to the highly dynamic nature of javascript.
The biggest challenge at this point would be adoption. In practice, with so many packages depending transitively on things like left-pad and is-odd, introducing a consolidated package would likely just fragment things and make it worse.
Assuming that the issue of breaking thousands of packages à la left-pad is solved, I don't find micro-libraries to be particularly distasteful.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The points you make are important ones with regard to using library methods. The question then becomes: do we need a separate library/dependency/liability for every trivial function (even if trivial >> 10 sec)?
(for context, I approach this from the Java ecosystem, where a small number of almost-de-facto-standard libraries are available to serve most needs)
I think that javascript is unique for a couple of reasons. Unlike most languages, javascript has a minimal standard library, so a lot of functionality that you'd expect to be included with the language isn't present, so people turn to NPM.
Someone could conceivably create a package to include all the trivial functionality that is otherwise being included piecemeal, but this package would grow to be pretty big. Then we're including a bunch of functionality we don't necessarily need to get access to one or two functions.
Definitely not to start a (reverse) war of the languages, but the java standard library is wholy inadequate. Together with tree shaking on the one hand, and the fact that a typical webapp pipes a lot of javascript on the other, there is no technical or practical impediment to having bigger libraries.
I actually feel like Java's standard library has improved considerably, especially with Java 8.
Tree shaking would solve the issue of depending on a handful of functions from a large library, but tree shaking also requires some effort to set up and can be imprecise due to the highly dynamic nature of javascript.
The biggest challenge at this point would be adoption. In practice, with so many packages depending transitively on things like left-pad and is-odd, introducing a consolidated package would likely just fragment things and make it worse.
Assuming that the issue of breaking thousands of packages à la left-pad is solved, I don't find micro-libraries to be particularly distasteful.