3 ms·

The JavaScript world is littered with stuff comparing to which your patch seems like a complex project. See those examples: https://www.npmjs.com/package/is-od

The JavaScript world is littered with stuff comparing to which your patch seems like a complex project. See those examples: https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-odd https://www.npmjs.com/package/is-even https://www.npmjs.com/package/is-even https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/left-pad https://www.npmjs.com/package/is-whitespace-character https://www.npmjs.com/package/is-whitespace-character https://www.npmjs.com/package/isarray https://www.npmjs.com/package/isarray

JaggerJo 15d ago
what a broken ecosystem.. The crazy thing is not that the package exists, but that it is used by JS devs.
- yurishimo 15d ago
  There’s a bit more nuance as to why. It’s not fair to say that the average JS dev is reaching for a package like is-odd/is-even. Years ago when npm was just getting started there was a lot of experimentation and land grabbing for packages. A few “prolific” developers were pushing these tiny utilities and then using them in their own projects which ended up being required as deps in other projects and then snowballed into is-odd being included in webpack at some point (I think I have that timeline roughly correct). It’s still a crappy problem for sure but it’s not fair to paint most JS devs with a brush so broad.
- junon 15d ago
  I feel like I have to remind people of this quite often, but the history is such that npm was lightweight at one point, bundling wasn't a thing, and while `isodd`/`iseven` are of course silly, things like `isarray` were not functions that existed back then (we didn't have Array.isArray). `typeof [] === 'object'` in JS, so e.g. my package `is-arrayish` checked for a similar structure to an array (whereas Id guess `isarray` checked for the prototype). `isarray` failed for the `arguments` keyword, which was needed for variadics before argument spreads were added to the language I believe in ES5. So of course they don't make sense now. But they were created for a reason. Before even Markov chains were a fad - let alone LLMs - we were trying to be as efficient as possible and maximize code reuse I stead of writing the same helper functions over and over again. That's what you're seeing.
  - b112 15d ago
    [flagged]
    - junon 15d ago
      I think a lot of things end up that way, just at different timescales. Best we can do is learn from them and start again, IMO - however that looks.
    - toyg 15d ago
      "The road to Hell is paved with good intentions". Still true, probably thousands of years after the sentence was coined.
  - zarzavat 15d ago
    Yes and the critical issue was tree shaking. Nowadays we have tree shaking so it doesn't matter as much but in the past people preferred small single function packages because they had less impact on the download size.
  - ChiperSoft 15d ago
    Additional Context: for about two years functional programming was REALLY popular in the Node community. It was a fad to chain tons of tiny functions together, and thus lots of people wrote tons of tiny functions. This is why lodash/fp exists.
  - wat10000 15d ago
    I don’t think it ever made sense. Code reuse improves efficiency when the code can be shared in memory, or when it needs to be updated and you only have to change it in one place. JS packages don’t give you sharing beyond what you’d get from copying the code. And these little things don’t need to be updated, and in fact you probably don’t want them to be. It’s a case of doing something without understanding why it’s done. Packages are good, code sharing is good, so use it for everything. But it misses why they’re good.
    - junon 15d ago
- austin-cheney 15d ago
  Everything that touches JavaScript in the corporate world feels broken. Look at any full stack job post. It’s a mess of tech stack nonsense on the backend for people who are terrified of JavaScript and a layering of framework madness on the frontend for people who are still terrified of JavaScript. So it should be no surprise to see packages like those in common use when people aren’t really writing, or even reading, the real code anyways. That is just the coding aspect of it. There are many additional challenges to working with a bunch of cowards whose primary job is to pretend to be something they clearly aren’t.
- dahart 15d ago
  There’s not much evidence these are being used, only that they are dependencies for something else; that’s why the download numbers are so high. I wouldn’t say it’s broken, I’d say there are tradeoffs, and devs have known this and discussed it since the start of npm or any package manager. You automatically get some bloat when you use other people’s software. That’s the downside. The upside is you don’t have to write the code yourself and you can create things more quickly by not solving problems that others have already solved. It’s worth noting that AI has some of the same tradeoffs. The quality of what you get is still proportional to your prompting & reviewing effort, and spending low amounts of effort often results in similar amount of bloat.
- shevy-java 14d ago
  PHP devs are happy that npm exists. That way there is always a worse ecosystem down below.
domh 15d ago
These packages are basically memes at this point... Those download figures cannot be accurate for real production usage. I don't believe any programmer is actually using these. isarray and left-pad are at least functions that didn't used to be in the standard library, to slightly excuse them.
- sumtechguy 15d ago
  I would not bet on that assumption. I have seen some wild code over the years from devs. With 'ai' type coding going on now too you may see them be used even more.
  - domh 15d ago
    I would've actually thought AI would slightly improve upon this situation. At least in my experience claude seems to write a lot more little utility functions itself rather than reaching for a package from npm to do something. Requiring an `npm install` before getting something working risks triggering a permissions gate.
  - brookst 15d ago
    Opus and fable both are pretty judicious about bringing in dependencies, at least for me. They often argue against and and write even decently large modules to avoid pulling stuff in.
    - sire-vc 14d ago
      They never install packages for me and love handrolling large amounts of e.g. parsing code where a library exists. I have to keep telling them 'look for a large popular dependency' when they start writing huge functions that obviously already exist. Was doing something with OSM the other day and Opus basically started reimplementing NetTopologySuite.
- whywhywhywhy 15d ago
  Major libraries used them so yeah the numbers are real, left-pad was in every react and babel install.
vachina 15d ago
Whenever I see a npmjs project I nope out of it. I’d rather spend $50 on tokens to reimplement whatever JS slop in Python or Go.
JohnMakin 14d ago
is-even implementation: > 'use strict'; > var isOdd = require('is-odd'); > module.exports = function isEven(i) { > return !isOdd(i); > };
- d3Xt3r 14d ago
  I thought you were joking, but then I checked the code... holy shit, it is real. Surely the author's gotta be trolling, right?

JaggerJo 15d ago

what a broken ecosystem.. The crazy thing is not that the package exists, but that it is used by JS devs.

yurishimo 15d ago
There’s a bit more nuance as to why. It’s not fair to say that the average JS dev is reaching for a package like is-odd/is-even. Years ago when npm was just getting started there was a lot of experimentation and land grabbing for packages. A few “prolific” developers were pushing these tiny utilities and then using them in their own projects which ended up being required as deps in other projects and then snowballed into is-odd being included in webpack at some point (I think I have that timeline roughly correct). It’s still a crappy problem for sure but it’s not fair to paint most JS devs with a brush so broad.
junon 15d ago
I feel like I have to remind people of this quite often, but the history is such that npm was lightweight at one point, bundling wasn't a thing, and while `isodd`/`iseven` are of course silly, things like `isarray` were not functions that existed back then (we didn't have Array.isArray). `typeof [] === 'object'` in JS, so e.g. my package `is-arrayish` checked for a similar structure to an array (whereas Id guess `isarray` checked for the prototype). `isarray` failed for the `arguments` keyword, which was needed for variadics before argument spreads were added to the language I believe in ES5. So of course they don't make sense now. But they were created for a reason. Before even Markov chains were a fad - let alone LLMs - we were trying to be as efficient as possible and maximize code reuse I stead of writing the same helper functions over and over again. That's what you're seeing.
- b112 15d ago
  [flagged]
  - junon 15d ago
    I think a lot of things end up that way, just at different timescales. Best we can do is learn from them and start again, IMO - however that looks.
  - toyg 15d ago
    "The road to Hell is paved with good intentions". Still true, probably thousands of years after the sentence was coined.
- zarzavat 15d ago
  Yes and the critical issue was tree shaking. Nowadays we have tree shaking so it doesn't matter as much but in the past people preferred small single function packages because they had less impact on the download size.
- ChiperSoft 15d ago
  Additional Context: for about two years functional programming was REALLY popular in the Node community. It was a fad to chain tons of tiny functions together, and thus lots of people wrote tons of tiny functions. This is why lodash/fp exists.
- wat10000 15d ago
  I don’t think it ever made sense. Code reuse improves efficiency when the code can be shared in memory, or when it needs to be updated and you only have to change it in one place. JS packages don’t give you sharing beyond what you’d get from copying the code. And these little things don’t need to be updated, and in fact you probably don’t want them to be. It’s a case of doing something without understanding why it’s done. Packages are good, code sharing is good, so use it for everything. But it misses why they’re good.
  - junon 15d ago
austin-cheney 15d ago
Everything that touches JavaScript in the corporate world feels broken. Look at any full stack job post. It’s a mess of tech stack nonsense on the backend for people who are terrified of JavaScript and a layering of framework madness on the frontend for people who are still terrified of JavaScript. So it should be no surprise to see packages like those in common use when people aren’t really writing, or even reading, the real code anyways. That is just the coding aspect of it. There are many additional challenges to working with a bunch of cowards whose primary job is to pretend to be something they clearly aren’t.
dahart 15d ago
There’s not much evidence these are being used, only that they are dependencies for something else; that’s why the download numbers are so high. I wouldn’t say it’s broken, I’d say there are tradeoffs, and devs have known this and discussed it since the start of npm or any package manager. You automatically get some bloat when you use other people’s software. That’s the downside. The upside is you don’t have to write the code yourself and you can create things more quickly by not solving problems that others have already solved. It’s worth noting that AI has some of the same tradeoffs. The quality of what you get is still proportional to your prompting & reviewing effort, and spending low amounts of effort often results in similar amount of bloat.
shevy-java 14d ago
PHP devs are happy that npm exists. That way there is always a worse ecosystem down below.

domh 15d ago

These packages are basically memes at this point... Those download figures cannot be accurate for real production usage. I don't believe any programmer is actually using these. isarray and left-pad are at least functions that didn't used to be in the standard library, to slightly excuse them.

sumtechguy 15d ago
I would not bet on that assumption. I have seen some wild code over the years from devs. With 'ai' type coding going on now too you may see them be used even more.
- domh 15d ago
  I would've actually thought AI would slightly improve upon this situation. At least in my experience claude seems to write a lot more little utility functions itself rather than reaching for a package from npm to do something. Requiring an `npm install` before getting something working risks triggering a permissions gate.
- brookst 15d ago
  Opus and fable both are pretty judicious about bringing in dependencies, at least for me. They often argue against and and write even decently large modules to avoid pulling stuff in.
  - sire-vc 14d ago
    They never install packages for me and love handrolling large amounts of e.g. parsing code where a library exists. I have to keep telling them 'look for a large popular dependency' when they start writing huge functions that obviously already exist. Was doing something with OSM the other day and Opus basically started reimplementing NetTopologySuite.
whywhywhywhy 15d ago
Major libraries used them so yeah the numbers are real, left-pad was in every react and babel install.

vachina 15d ago

Whenever I see a npmjs project I nope out of it. I’d rather spend $50 on tokens to reimplement whatever JS slop in Python or Go.

JohnMakin 14d ago

is-even implementation: > 'use strict'; > var isOdd = require('is-odd'); > module.exports = function isEven(i) { > return !isOdd(i); > };

d3Xt3r 14d ago
I thought you were joking, but then I checked the code... holy shit, it is real. Surely the author's gotta be trolling, right?