Wouldn’t the alternative simply be bigger libraries grouped around common functionality or extension points? Like jQuery or similar (only an example, not sure what is hip today).
I’d rather trust a fairly big library with an organized open source group behind it than thousands of small libraries by unknown developers.
Another good example: .NET Core. I trust that Microsoft hires good people who can update the core libraries in .NET Core to not do dumb and unexpected things. I trust Microsoft to have controls that check for malicious behavior and prevent / fix that quickly. I trust Microsoft to vet all open-source dependencies they decide to integrate into their products.
Also the legal team likes this a lot more too. If a data leak occurs due to some library that Microsoft wrote, we have one company to sue. If it's a react package, who the hell do we go after? Most of these are "at will" / MIT license style things, so we are more or less SOL anyways, but legal teams don't like hearing that.
You also get at a more fundamental question. What is trust? Why can we trust a larger organization over a collection of individuals? Are they not the same thing? What social structures make one more trustworthy over another?
There's a great book on this by Bruce Schneier called Liars and Outliers. I highly recommend you read it.
fwiw, I've been doing professional JS (mostly server, good amount of client) for about 5 years now and have never pulled in a single function package before as a direct dependency. Every team I've been on has used Lodash or Underscore in the capacity you describe.
I agree that this is the sane alternative, but sanity does not seem to be winning out. Our friend number-is-nan, for example, has 12 million downloads a week.
It’s like someone saw how much the is-odd/is-even (yes one of those first two depends on the other and just returns the inverse with !) packages are downloaded per week and said “hold my beer”
Of course they don’t hold a candle to “is-number” which has 29M/week
Of course this is completely unrepresentative of reality because “yolo just install dependencies at deployment” may mean it’s downloaded 5 or 10 or 50 times for a high traffic site/service with a bunch of backend installations.
The NaN library is literally just testing if the value is a number with typeof v === 'number' then tests if v !== v. This is not something you need a library for at all, big or small.
Yeah, this is my philosophy when developing Erlang software as well (also seems to be shared by most of that community). A few dependencies less are always worth a few functions more.
Yeah, but the thing is that it's just unnecessary.
isNaN() has been in the language forever. And in case you really need Number.isNaN() (because it's weird for isNaN('foo') to be true), it's been there for quite a long time too. Not enough to be on IE, sadly, but certainly more than enough to be on the modern JS engines React Native runs on.
So, at least for React Native, the package number-is-nan shouldn't be necessary at all. But it's probably a transitive dependency, and that's basically the problem with all these sort of polyfill packages: you might not need them, but a library that runs on older engines on which you depend (directly or transitively) does need them, so you end up paying the price anyway.
no, isNaN has been in the language for quite a while, num !== num has been in the language forever.
which actually if I look at number-is-nan it returns
return typeof value === 'number' && value !== value;
I never use the typeof value === 'number' myself because I always know if what I'm checking is NaN should be a number of not, but probably that's a bad habit to get into.
To criticize this organization, you would need to understand why people find that to be valuable and show a better approach.
You’re attributing it to “culture” but there may be deeper, less arbitrary reasons. Look up “ponyfill” if you are interested in learning about it.