10 useless NPM Package with millions of downloads

1. is-odd

Detect number is odd or not - 2M downloads/month 🎉

2. is-even

Detect number is even or not - 855k downloads/month 🎉

3. upper-case

Convert a string to upper case - 27M downloads/month 🎉

4. is-number

Detect a number is number or not - 194M downloads/month

5. store2

For storing and getting from localstorage - 9.7M downloads/month 🎉

6. array-flatten

Flatten nested arrays - 103M downloads/month 🎉

7. split-string

Split a string at any desired position - 67M downloads/month

8. is-boolean-object

Detects a value is boolean or not - 52M downloads/month

9. array-includes

Check if a value exists in an array or not- 52M downloads/month

10. ismobilejs

Detects if mobile or not in browser or server - 170k download/week 🎉

If you know any other such useless plugin , please comment down below.

Also I have started posting on twitter related to frontend tips and tricks. You can follow me at- https://twitter.com/frontend_jsx

Comments

[Keff]

funny, know what's even funnier? check out the code for is-even:

'use strict';

var isOdd = require('is-odd');

module.exports = function isEven(i) {
  return !isOdd(i);
};

It's fricking is-odd, negated... And then is-odd depends on is-number, crazy stuff

[Garik Suess]

It gets even better: there is a package named "is-uneven", which, you guessed it, depends on is-even and negates. You couldn't make this stuff up.

npmjs.com/package/is-uneven

[Siddharth]

I guess you still can make is-unodd, which doesn't exist

[Vukky]

Are you sure?

[Siddharth]

:D

[Siddharth]

is-unodd negates is-uneven negates is-even negates is-odd which returns !!(~~i & 1)

[Keff]

Incredible, imagine what would happen if suddenly they remove is-even package... like what happened with this other package of which I don't remember the name of... which broke quite a lot of stuff...

[Jez McKean]

leftpad iirc

[Keff]

Yes, that's the one, thanks!

[Jazz Brown]

Hmmmm very dubious that it was created and commited all in the last two days.

[leob]

I like it that the author says "Help with this big and important project is very appreciated", at least he's got humor and he's probably also aware that the whole thing is just a joke!

[Ishan Tiwari]

Who on earth has downloaded it?

[jzombie]

The people who use these packages: npmjs.com/browse/depended/is-even

[Jyotishman Saikia]

haha! Even i am finding those folks

[Raí B. Toffoletto]

WTF......

[LuisPa]

And if you think about this for a second, it looks like is using another package to inflate the numbers of the downloads for both packages.

I've seen this in a lot of packages, all the time comes from the same publisher.

[weirdguppy1]

Lmao 😂

[Jyotishman Saikia]

haha! 🤣 . my reaction was same when i discovered it.

[jeck labasan]

lol hahahaha

[Amohammadi2]

🤣🤣🤣🤣

[Jyotishman Saikia]

haha Keff ! funniest part is that is has millions of downloads

[Misael Braga de Bitencourt]

🤣🤣🤣🤣🤣🤣🤣🤣🤣

[IArny]

How can is-number have less downloads then is-odd if it depends on is-number

[Jyotishman Saikia]

interesting

[Ansile]

I mean, i get the meme value in in is-odd/is-even packages, but you got useful packages mixed in here too.

array-includes is a polyfill, first published 7 years ago.
array-flatten is kinda the same. It's not a polyfill, in a technical sense, but Array.prototype.flat is a new feature and the package pre-dates it.

ismobilejs is a device os/type/etc detector. Some apps definitely need that.

And store2 is a wrapper with a huge amount of features, some convenience-based (e.g. modifying currently stored value instead of manually doing get+set), and some unique (e.g. checking how many space is left).

Don't just cheapen the work that went into these packages with a "useless" label, if you simply don't know what's the intended use for them.

[Jyotishman Saikia]

hi Ansile. I am using all these javascript features in my current project without these packages with some minimal lines of code. so, the label of useless is added.

[shadowtime2000]

I mean for is-odd/is-even your probably able to do it without it with minimal lines of code, but like just because array-includes and array-flatten aren't as important due to the new features Arrays have doesn't mean you should mark it as useless and try to make a joke out of those who download it. I don't understand how your comment works for store2 because that seems to have a lot of features and convenience which you probably can't replicate "without these packages with some minimal lines of code", and for ismobilejs I don't know much exactly how complex it is to detect if its on a mobile device or not, but it sure seems like its not something you could do with some minimal lines of code.

[Jyotishman Saikia]

I believe store2 is just a feature friendly package of a combination of localstorage and sessionstorage.
I believe any developer can achieve these all tasks

[HamishWHC]

And yet you still use NPM packages. Everything is just for convenience. Devs could do everything themselves, but they don't! Why bother reinventing the wheel?

[shadowtime2000]

I mean yeah you could use localStorage and sessionStorage without store2, but store2 still adds convenience that some people may like for their project, so you shouldn't go and just try to make a joke out of those people saying they are using a useless package. If you look at the README for store2, it adds some features that help you write cleaner code, like with the transact feature, without having to re-invent the wheel.

[Jovica Aleksic]

Seems you're not in the line of work for more than a couple of years then :)

[Jyotishman Saikia]

thanks.

[Keff]

I have to agree with you here, I did not like the "useless" label neither, and was going to point that out. But I got distracted with is-even and is-odd.

[Aran Leite]

Yes, but those polyfills are still being downloaded, in 2021. 10m+ times every week.

[shadowtime2000]

Yeah, because people want to support older browsers.

[Jyotishman Saikia]

yes .

[József Sallai]

While there are some packages here that could be considered useless, I can see a potential use case for them, and most of the time it boils down to functional programming approaches and code readability.

For example:

arr.filter(isOdd)
// instead of
arr.filter(n => n % 2 === 1)

// or

arr.map(upperCase)
// instead of
arr.map(s => s.toUpperCase())

Is it worth installing additional packages only to make the code slightly shorter and more readable? That depends on who you are and what your use case is. Some people will like that idea, others will be left with a sour taste in their mouth. Personally, I'm indifferent but I still wouldn't call the packages useless just because I can't find any use for them.

As others pointed out already, some of these packages are now used as polyfills for older browsers that don't have the said feature. You may not care about IE 11 but there are developers who do. Again, it's entirely subjective but IE 11 still has a userbase - even if it's not that big. There's still a lot of corporations who reinforce using IE for their management systems, for example.

store2 has way too many convenience features to be called "useless". Again, just because you don't find any use for it and you're a 10X developer with a great ego who knows how to reinvent the wheel and implement those features manually, doesn't mean that it's useless. You could think of this package as a superset of localStorage. Would you say TypeScript is useless because JS exists and you can just use JS instead of installing additional dependencies just for the sake of convenience?

ismobilejs is definitely not a useless package. I don't see the point of reinventing the wheel by copying and pasting weird regular expressions from the internet when you can just use what the community already has to offer. This is kinda the point of open source and package-based language ecosystems -- reusability. This package is something I've personally used and I genuinely don't see why you think it's useless.

So yeah, in conclusion: this article is heavily subjective and completely based on what your definition of "useful" is. It doesn't take into consideration any potential use case these packages may have and your only counter-argument is that you can implement them yourself easily - which in itself is not necessarily a good enough counter-argument. I'm surprised lodash or its split packages aren't listed.

[Jyotishman Saikia]

thanks József Sallai ! for the feedback. I am neither a 10x developer nor an egoistic person. All these are personal views and my own experience. If I try to write all these disclaimers in my article nobody would be interested in reading . But at-least a section of developers would be there who would agree that all these features can be achieved with just some minimal effort.

[József Sallai]

Which is completely fine, you are entitled to your own opinion. I'm definitely not saying you're the only one who has this opinion - again, it comes down to your development practices and use case. If you prefer writing utility functions yourself and import those instead of installing additional packages, there's nothing wrong with that.

But I still think "useless" is a bit harsh, at least for some of these packages. I can totally see most people agreeing that is-odd and similar packages are useless - in fact I used to joke about it too. But I don't think store2 or polyfills should go under the same category.

I'm not saying you should add a disclaimer (albeit I don't think it would really hurt your article in any way), but it would be nice to include at least some potential use cases in it instead of just laughing at the people who use these packages. It will make your article less opinionated and more unbiased, while also not discrediting the authors of the packages and the people who use them.

[Aran Leite]

Babel has polyfills, so you don't need to write old JS or use outdated packages to support old browsers.

[shadowtime2000]

Yes, Babel has polyfills, but not everyone wants to create complex build systems and may just want to stay a little more basic. Saying that a polyfill package is useless just because Babel can provide it is a poor argument. Packages aren't useless just because other tools can provide the same thing. It comes down to developer preference on whether they want to use Babel or whether they want to be simpler.

[Seniya Rathnayake]

Believe me or not, lodash was first to pop in my mind after reading the argument that we can implement these with minimal lines. XD

[Jyotishman Saikia]

lodash has a lot of features not just one thing to do. so believe it is not useless

[shadowtime2000]

store2 adds a lot of features built upon standard browser JS features, just like lodash, except lodash is much easier to replicate than store2. By your logic isn't store2 not useless then, because it has a lot of features. Contradictory, don't ya say?

[mcmath]

I’m going to go out on a limb and say that none of these are useless. Take upper-case, for example. I imagine it’s supposed to be useless because we already have toUpperCase(). But sometimes we want to do this:

let upperCaseStrings =
  lowerCaseStrings.map(upperCase);

Whereas this won’t work:

let upperCaseStrings =
  lowerCaseStrings.map(String.prototype.toUpperCase);

Yes, it's easy to implement yourself. In fact, I have (many times). Maybe I'll download upper-case next time instead.

[Ghaleb]

Yes, it's easy to implement yourself.

What's there to implement? Just use an arrow function

// typical use-case
const upperCaseStrings = lowerCaseStrings.map(s => s.toUpperCase())

// if you need it often
const upperCase = (s) => s.toUpperCase()
const upperCaseStrings = lowerCaseStrings.map(upperCase)

[mcmath]

But inline arrow functions are recreated every time they are evaluated. This may not be a problem in most circumstances. But in React, passing an inline function to a pure component causes it to re-render every time its parent renders; passing the same exact instance of a function may result in a significant performance boost. It may be an edge case, but it's one that I've actually encountered several times.

Yes, you can define the function somewhere else if you need it often. But then you've just reimplemented the package, proving that it does actually serve a purpose.

[Phantz]

This is a micro optimization fallacy. As every single performance analyst, and even the V8 engineers have said multiple times (there's some good talks on youtube) - don't micro optimize.

Now that we've got that out of the way, let's talk about optimization. As I just so happen to be somewhat obsessed over it too :P. Since around the mid 2010s (2015 maybe? Can't remember), V8 (the state of the art VM most javascript runs on) has inline cache. This is why higher order functions suddenly saw a massive speed boost around this time. You may remember people telling you to not use higher order functions prior to this change. There is a stack overflow thread summarising the details of the aftermath. I remember it being about different array iteration methods and their speed.

Anyway, that's the inline cache for optimizing out inline lambdas. If we want to go into nitty gritty details, the cache is actually for all expressions in Applicative Normal Form.

Anyway, this is far from being the only optimizing technique V8 has - it's supposed to make javascript ridiculously fast, so it has a state of the art JIT.

The point of all this effort from some of the greatest engineers of all time, is so that users won't care about highly superficial "optimizations" such as avoiding arrow functions.

By the way, is storing the arrow function in a variable, then using that, considered worse than pulling in an entire dependency? ;)
(this is a joke - don't actually store all your arrow functions in variables out of paranoia, for reasons mentioned above)

[mcmath]

I understand all that, and I agree that you generally shouldn't worry about inlining functions. But the example I gave was pure components in React. Pure components check the properties they are passed with Object.is() every time their parent component renders. If all the properties are the same as the last render, the pure component can skip rendering, which may be a significant performance boost when rendering complex components or lists, for example. If you pass an inline function, Object.is() always fails, so you break the optimization that pure components provide. There is a React hook called useCallback() designed to circumvent this problem, but for simple cases like upperCase(), it's unnecessarily verbose.

Yes, you can easily define the function yourself, which is what I do. But if it's useful when I define it myself, then it's useful when someone else defines it in an NPM package.

[Jyotishman Saikia]

Hi Akim! why dont you use the css text-transform property for this? Any corner case?

[mcmath]

CSS text-transform is a good option, but it only works in CSS. In a non-browser environment, that won't work. I'm not saying there are not often better alternatives to these packages. But all of them are useful in certain (possibly rare) circumstances.

[Mike Talbot ⭐]

Case insensitive array searching? List searching?

[Jyotishman Saikia]

toLowerCase() would work here right?

[Mike Talbot ⭐]

Same issue as the comment above. Might need to do it for a map. I have these functions defined for that purpose. Though I agree, I wouldn't import a package for a 3 line function :)

[Jyotishman Saikia]

thats my whole point is. anyways thanks for your feedback.

[Phantz]

yeah we should probably have a package for every single prototype method since, as you said, we can't use methods in higher order functions.

Oh wait, arrow functions exist! Phew, what a relief.

Although I suppose arrow functions could be considered too much effort, so we may as well have a package for every single method anyway. Let's do that!

/s

[mcmath]

But see my comment above about inline arrow functions being recreated every time they're evaluated. Maybe this doesn't matter in 99% of cases, but if it matters 1% of the time, then it's not useless in my book.

[Alain D'Ettorre]

Actually, array-flatten and ismobilejs are not that useless. For example, array-flatten could be a little bit older than the standard Array.prototype.flat, which was not available before 2019.

[Piotr "MoroS" Mrożek]

Same with array-includes: it might have been a polyfill at some point. I didn't check the dates on it though, so I'm only assuming that was the case.

[Jyotishman Saikia]

javaascript array includes has support for all browser.

array-includes has a weekly downloads of 12,377,891.

So , I am thinking who are these 12,377,891 folks.

[Ansile]

Definitely not "all browsers". If you bothered to check, there are a few browsers that do not support it, but they definitely exist.

For example, Internet Explorer 11 is definitely still supported in many websites.

[Jyotishman Saikia]

there are a bunch of browsers available in the market. But we consider only the top modern browsers.

internet explorer is going to end very soon. So , i think majority of users dont use this browser as they have moved to edge.

[Mike Talbot ⭐]

15% of my users. UK corporates that are not technical (Plumbers, Builders, Contractors etc). IE11 still shipped with W10. etc etc. Check out the Wikipedia stats, they still get ~5% of visitors on IE11. Can't wait until I say "not supported" lol.

[Aran Leite]

In which case you can use Babel to turn you code into pre-ES6 instead of importing such a package.

[Ansile]

Actually, that is wrong. Babel by itself cannot transform prototype methods. That would require type information, which babel does not have. For example, a.includes(b) could be a call to an array method, or a method of your own Collection class (e.g. mobx ObservableArray).

And while babel turns language syntax into pre-es6, you still require polyfills.

You can get them all in a 'bulk' by importing from corejs, but it's a different story.

[shadowtime2000]

As said before, not everyone wants to use Babel and setup complex build environments.

[Aran Leite]

Said complex build environment:
babel.config.json
{
"minified": true,
"presets": [["@babel /env", { "targets": { "node": "current" }}]]
}

package.json
"scripts": {
"build": "babel src --out-dir dist",
},
"devDependencies": {
"@babel /cli": "^7.14.5",
"@babel /core": "^7.14.6",
"@babel /preset-env": "^7.14.7",
}

[shadowtime2000]

Man you really just picked one part out of my comment which is the only part which you knew you could counter and then ignored the actual point. It is kind of irrelevant to the point that it isn't that complex, not all people want to use Babel, and saying that a package is useless because another package can do it is a horrible mindset and a horrible argument.

[Aran Leite]

Look at the comment I answered. "As said before, not everyone wants to use Babel and setup complex build environments." just that. Even if we pick your other replies, they were "Yeah, because people want to support older browsers" and "Yes, Babel has polyfills, but not everyone wants to create complex build systems and may just want to stay a little more basic"
The second one's basically the one I answered, so stop coming up with random stuff. Babel not only has polyfills, but isn't complex and supports older browsers. That's all 3 of your replies countered.

As for "not everyone wants to use Babel", that's life. In a world where build tools or Babel didn't exist, a package that's a polyfill was useful. But it's been established as a great tool for quite some time now, so it's just using outdated/more complex solutions. Or in cases where you can't, which brings us to:

array-includes is used by 442 packages. One of those is create-react-app. Each app created with it also downloads array-includes. Which is not to say that people are willingly choosing to use it.

By the way, Babel has 24m weekly downloads, for all the "not everyone wants to use Babel and setup complex build environments" talk.

[Ishan Tiwari]

Begginer JavaScript interview: Find out if the number is odd or even.
Me: Wait let me import is odd

[Jyotishman Saikia]

haha !

[Jovica Aleksic]

:D

[Siddharth]

What about -? It has almost 23,000 downloads a week. I'm guessing people accidentally do npm i something - D. Next thing to do is make a package called --

[sakethk]

Then i can plan npm package for addition, subtraction, multiplication, division 🤔

[Jyotishman Saikia]

haha! definitely you should try building them.

[Jakub T. Jankiewicz]

isMobile is not that useless. It's not that trivial to create this function yourself. But the code is just bunch of regex that tests userAgent string. It don't look very reliable. In one of my projects I have very long regex that test if something is mobile or even longer if it's a tablet.

[Eliezer Peña]

In my personal experience is better check the viewport size (i.e: with window.matchMedia)

[Jakub T. Jankiewicz]

I think that it fail on iPhone with retina in horizonntal mode. vewport size is not best way to test for mobile.

[Eliezer Peña]

I think not, because the viewport pixels is not based on the real pixels of the device. You can also test and share your results ;)

Here is some documentation about how the CSS Units works webplatform.github.io/docs/tutoria...

[Raí B. Toffoletto]

I think most of those downloads are as dependency of other packages... I don't understand why any project would use them, takes more effort to import those then to write they simpler functions. Anyway.... check out you libs before implementing them folks. 😉

[Jyotishman Saikia]

agree Rai B! Even I am thinking why would someone need these modules in their projects.