They walk among us unnoticed.
They walk and talk like everyone else. But don’t be fooled by their innocent looks.
You see, they’re not like you and me. They don’t believe in the same things we do.
They are… The JavaScript left-padders.
What is a JavaScript left-padder?
A left-padder is a JavaScript developer who considers creating and using a module who’s sole purpose is to left pad a string, a good practice.
They are known to create extremely tiny modules. Some of which are only 17 lines of code.
And even a 17 line module is considered large by some left-padders. Hidden inside the left-padder ranks are what I like to call: The True Believers.
The True Believers are the most extreme left-padders. They’re publishing modules that are just 4 lines of code. Modules that have only 1 line of business logic.
The madness…
Or is it?
Everyone thought React was crazy at first too…
It’s easy to be cynical when you come across these tiny seemingly useless packages.
But they’re a part of a growing practice to share and reuse even the tiniest pieces of code. These snippets are so tiny they barely pass as a StackOverflow answer.
It initially seemed to me that using a module so trivial such as “isArray”, would hardly be worth the trouble.
And yet, this module had over 4 million downloads last week. And over 100 dependent packages.
Was I missing something?
NPM as a Snippet Database
When was the last you copy pasted a JavaScript snippet from StackOverflow?
And when was the last time you thought to yourself: “This snippet is actually pretty useful, I should bookmark it or something for future use.”
But what if instead of simply bookmarking, you took the time and published that snippet as a JavaScript module on npm? That way you and other developers would have easy and reusable access to it.
Heck, maybe someone will even find a way to improve it.
Yeah, But…
I know, I know. A developer should never copy and paste something without fully understanding it first. And once you understand something, you easily remember it and can use it again.
I agree with you. Or at least with the first part.
We should all know and understand the logic behind left padding a string and how to detect an array.
But understanding the logic of something and remembering the exact syntax are two different things.
An Example
Let’s take the notorious isArray module as an example:
let toString = {}.toString;
module.exports =
Array.isArray ||
function(arr) {
return toString.call(arr) == '[object Array]';
};
Let’s say I understand the logic here. Calling the Object toString() function with an array as its context will always return the string '[object Array]'
But a year from now, or even a month, I’ll be working on a new project.
Will I remember the exact string comparison syntax? Or will I wonder “Was it ‘Object array’ or ‘object Array’?”
Granted I could easily type the function call in my browser’s console, get an answer, retype the whole function again under the private utils module of my new project. But how is that better than npm install isarray --save ?
Why should I go through all of that cognitive load when there’s a perfectly good package just sitting there?
Some very smart people are doing it
Sindre Sorhus is someone who I file under the “Very talented open source developers” category.
He helped to create projects such as Yeoman and TodoMVC. He created Pageres, Chalk and the hot new testing library AVA.
He’s the curator of all of the awesome lists on GitHub. Which I assume makes him awesome by default.
He’s also one of the most vocal advocates of one-liner npm JavaScript modules. And he makes a few very good points:
“Imagine if PC manufacturers all made their own CPUs. Most would do it badly. The computer would be more expensive and we would have slower innovation. Instead most use Intel, ARM, etc.
This would not be possible if it weren’t for how npm works. The beauty of being able to use nested dependencies means I don’t have to care what dependencies a dependency I use have. That’s powerful.
Some years ago. Before Node.js and npm. I had a large database of code snippets I used to copy-paste into projects when I needed it. They were small utilities that sometimes came in handy. npm is now my snippet database.
Why copy-paste when you can require it and with the benefit of having a clear intent. Fixing a bug in a snippet means updating one module instead of manually fixing all the instances where the snippet is used…
I want programming to be easier. Making it easier to build durable systems. And the way forward in my point of view is definitely not reinventing everything and everyone making the same stupid mistakes over and over.”
July 1st, 2015. sindersorhus on one-line node modules.
Don’t judge me: Hyper Modular Packages still make me laugh sometimes
I too am human. And in spite of everything I just said, when I saw the is-positive package for the first time, I giggled.
My first reaction was “why?!” But we covered that already.
My second reaction was of course: “I have to write an is-negative package now!!!”
But to my disappointment, an is-negative package already existed.
Then I noticed something. The is-negative package had one critical design flaw. It didn’t depend on the rock solid is-positive package. A travesty I couldn’t stand for.
Side note: There’s actually an explanation for that. The type check and positivity check in the is-positive module are written as a one-liner in the is-positive package. So non-numbers will also return true if is-negative used it. Meh.
I of course did the only responsible thing. I forked the is-negative module, updated the code, made sure all the tests were passing and sent in a pull request.
Just kidding. That’s crazy talk.
I created a brand new package called is-not-positive instead. Which I’m sure will take the JavaScript world by storm.
Side note: Before this post was published and without me letting anyone know about it, the is-not-positive package already had 19 downloads.
To Hyper Module or not to Hyper Module?
As I tried to show, there are perfectly good and valid reasons to create and use hyper modules. And some very capable open source developers find them quite useful.
But in spite of that, I can’t blame anyone who wants to write their own isArray for older browsers, or check positivity the good old fashioned way.
I do hope that if you ever need a module that checks if something is not positive, and returns true even for non-numbers, you will give is-not-positive a try 😃