I develop data visualizations. This is my personal blog. More about me.

Mini Modules

29. März 2016

My very personal opinion and 2 eurocents on the discussions surrounding the npm issues and the left-pad project: This post is not so much about the technological and social implications of the issues npm and the open source projects which had left-pad as a dependency faced. This is more about what I think regarding small/mini modules and the ecosystem which evolved around them. Personally, I really don’t care how many lines of code a module has. If it solves a need for someone else than myself, why not publish a single useful line of code as a module?

I think when discussing this, one has to take the whole ecosystem and it’s implications into account, not just the language itself. Unlike other languages which offer a unified VM or a supported runtime for your host system, JavaScript is strongly tied to the web and the runtimes provided by different browsers. There are so many interpreters/compilers/environments where JavaScript needs to work. It’s in a web developer’s DNA to work around the quirks and weird behaviour of different environments and solve cross browser issues. That’s why everyone was so fond of libraries like Prototype, jQuery, lodash and others. Their success is one part the patterns and ease of use they provide, but of course because they freed you from the one major pain when debugging web development issues which are of course the cross browser issues. And in recent years this isn’t even so much about the quirks of the major desktop browsers anymore. Think of all the mobile engines, think of the PlayStation browser, think of the poor guys who decided to spend their time developing websites with support for Google Glass.

The rise of mini modules in JavaScript stems from this: When you create code using JavaScript, a certain insecurity will remain if what you did will work everywhere in every kind of runtime that is out there. So even if you could of course implement little helpers like left-pad yourself easily, it’s hard and cumbersome to battle-test it under all kinds of circumstances.

This insecurity is the reason why I’m thankful as a developer to use a module which is hopefully well maintained by a bunch of other people, and more importantly used in the wild by others who will report and try to solve issues with the module (including myself in alternating the mentioned roles from time to time). This is how open source works for me and in that regard I don’t care if a module consists of a single or a hundred gazillion lines of code.

Filed under: Code