The best code is someone else’s problem

Possibly my favourite thing about modern Javascript is something that I often seem maligned by other programmers. I don’t understand how such an awesome feature can get so much vitriol. Its sole purpose is to remove the burden of extra cognitive load from us lowly developers and (at least partially) ensure a consistent development environment in a team. I am of course talking about the Javascript ecosystem.

Whoever had the idea of applying a package management paradigm to software libraries for the sake of development deserves some kind of award. Was RubyGems the first example of such a system? I’m not sure.

The most common complaint I hear about NPM and the micro-libraries contained within is some kind of puritanical, ascetic diatribe coupled with a kids-these-days attitude.

“Can’t programmers these days write their own left-pad algorithm? I could do that in 3 seconds with my head cut off” — or some other, self-aggrandising attempt to separate themselves from us mere Javascript devs.

Well, as a matter of fact, I could write my own left-pad algorithm but I won’t because the best code is someone else’s problem. The hypothetical ideal codebase is one in which there is only code related to the problem domain that the program is addressing. Everything else is collateral damage.

Let’s take an extreme example. The npm package noop2. Now, I could definitely write my own no-op function. In fact, I was born to write no-op functions, they are a personal speciality of mine. No-op functions are great for avoiding evil null references by providing a safe default. They are a very useful utility function but why bother importing a library just for a one-line function that does nothing?

If I use a utility function once, I’m probably going to use it at least twice, such is the nature of utility functions. So I probably don’t want to write the function in-line every time I use it and I don’t want to have this random noop variable in every file that it’s used in, that’s duplication. So I’ll abstract it out into a new file. Maybe I’ll call it utils.js.

And BAM! Just like that you’ve made a library that you now have to maintain which contains non-domain-specific code which just serves to pull you further from the platonic ideal of a computer program.

You also don’t benefit from the huge repertoire of talent available in the open source community or the extensive test suites written for such libraries (Yes, even noop2 has a test suite).

So don’t be afraid of npm install, even for a no-op function.

If you liked this article please remember to click the💚 symbol below to make sure more people get to read it!

Steven Poulton is a web developer and technical architect living in Manchester, England. In his spare time he likes to make indie music, make indie games and play with his indie cats.