The Fallacy of Tiny Modules

There is this myth, that if you break software into many tiny, super focused pieces, life is better. Bullshit.

Remember when object oriented languages were the shit? Breaking a complex system into small discrete pieces, exposing an abstracted interface, and reusing code by keeping everything highly specialized? Wasn’t it fun!

Call it what you like. Microservices, tiny modules, components, whatever. The bottom line is simple – at some point, someone has to put it all together and then, all the complexity is going to surface and the shit will hit the fan. Microservices are a nice idea and can be a valid architecture decision in some cases, but let’s not pretend that the people running the overall system are going to like it. Trading a large code based routing table for a large load balancer configuration isn’t better (actually, it is usually way worse).

Those promoting the idea of a utopia with a million tiny node modules living happily on npm keep using UNIX as their winning argument. The problem is that it is a false comparison. Small focused components making up the UNIX shell environment are only viable because UNIX is part of a curated distribution. Someone did the nasty hard work of picking a baseline functionality for you. More than that, that collection has been defined into a standard so that whatever UNIX flavor you are on, you can feel right at home.

Imagine if UNIX came with nothing but the kernel. No distributions. You install an empty kernel and then use some package manager to pick your copy, move, and list commands. Not much fun anymore, is it?. But wait, now go pick your flavor of grep, sed, and awk. Now make sure they all work well together and use the same flavor of regular expressions. Now make sure you keep everything up to date for security and stability.

This is what frameworks provide. In practice, a framework is a curated collection of functionality provided as a distribution. By picking a framework, you are picking a “single purpose node distribution” suitable for your application needs. The framework should allow you to swap the components with others but that baseline is the main value proposition. You buy into an ecosystem and in return you get a usable environment out of the box.

Tiny modules are a useful tool and a valuable design because they allow the construction of highly specific environments. But in most application development environments of any meaningful size, someone has to be the curator. Someone has to pick what’s being used and keep the collection both in sync and up to date, just like every UNIX distribution does.

You can argue that this someone is the developer building the application but that’s just not practical for the same reason you let others pick your operating system toolbox, your hardware toolbox, and even within node, your built-in toolbox. And this is just what’s under your web app. Don’t forget the entire front end side on top of it. Drawing the line at “everything on top of node” is an impractical and unproductive choice.

This is why frameworks matter. Go pick one.

(The author is highly biased as the maintainer of one such framework)