3 ms·

- Standard lib falling short - No control over the execution env (user's browser), which mean we need polyfills, transpilers, abstractions - Web is everywhere =

- Standard lib falling short - No control over the execution env (user's browser), which mean we need polyfills, transpilers, abstractions - Web is everywhere => JS needed for many many things => lots of library for all sorts of stuff => common problems extracted in small libs (which is has good and bad aspects) - Last point exacerbated by JS being a frontend and a backend language - Developpers tend to be more junior in average (not sure that's actually true, it's believable but never seen numbers) - NPM made it painless to add dependencies, so that's what happens

Sebb767 6y ago
A bit also stems from the fact that NPM installs dependencies as trees. I.e., if you and two of your dependencies use is-odd, you will have three copies of it laying around, possibly in different version.
- berkes 6y ago
  And now I'm stuck wondering why anyone ever would need to release a new version of isOdd. Apparently isOdd had 6 releases. Does that mean that the previous 5 times they had "calculating if a number is odd" wrong?
  - Sebb767 6y ago
    Looking at the commit history, they've mostly added checks for edge cases: https://github.com/jonschlinkert/is-odd/commits/master https://github.com/jonschlinkert/is-odd/commits/master Which is, to be fair, exactly the reason you'd use a library like this.
    - berkes 6y ago
      > Which is, to be fair, exactly the reason you'd use a library like this. There is a crucial nuance here: Which is, to be fair, exactly the reason you'd use a library. With which I mean to emphasize that -indeed- libraries are crucial. But nano-libraries, like nano-services are an antipattern. This could be a stdlib (ideally), a bundle (like Lodash) or even a numberUtils. Having a gazillion packages that have a rediculous biolerplate-to-code ratio, contain just one (well evolved!) function and so on, is doing more harm than good. A library "like this" is harmful. If only because it gives people an argument, or just the idea that libraries are stupid and should be avoided.

Sebb767 6y ago

A bit also stems from the fact that NPM installs dependencies as trees. I.e., if you and two of your dependencies use is-odd, you will have three copies of it laying around, possibly in different version.

berkes 6y ago
And now I'm stuck wondering why anyone ever would need to release a new version of isOdd. Apparently isOdd had 6 releases. Does that mean that the previous 5 times they had "calculating if a number is odd" wrong?
- Sebb767 6y ago
  Looking at the commit history, they've mostly added checks for edge cases: https://github.com/jonschlinkert/is-odd/commits/master https://github.com/jonschlinkert/is-odd/commits/master Which is, to be fair, exactly the reason you'd use a library like this.
  - berkes 6y ago
    > Which is, to be fair, exactly the reason you'd use a library like this. There is a crucial nuance here: Which is, to be fair, exactly the reason you'd use a library. With which I mean to emphasize that -indeed- libraries are crucial. But nano-libraries, like nano-services are an antipattern. This could be a stdlib (ideally), a bundle (like Lodash) or even a numberUtils. Having a gazillion packages that have a rediculous biolerplate-to-code ratio, contain just one (well evolved!) function and so on, is doing more harm than good. A library "like this" is harmful. If only because it gives people an argument, or just the idea that libraries are stupid and should be avoided.