In Defense of Hyper Modular JavaScript
Mike Groseclose

The Lego universe is a lot more like a monolithic JavaScript framework than it is like the npm universe.

Lego blocks are designed and manufactured according to standards set by Lego A/S. The appeal of Lego’s consistency is similar to the appeal of monoliths: you know everything will just work together, no glue required. If JavaScript monoliths had the staying power of toy manufacturers, they would still be around. But they don’t. Every two years something better comes along and… well, you know how it goes.

I don’t think I’d agree with your article even if you had a better metaphor. left-pad is not a red herring. npm is full of single-function packages just like it. It’s even worse in the closed source world. I’ve seen an environment where every tiny piece of every app lives in its own repo and is published to an npme server regardless of whether it needs to be reused. Engineers spend as much time finding prematurely abstracted components and getting them to work together as they do building new functionality. They do this not because they want to but because hyper-modularity has been mandated from the top down. These components come with a performance tradeoff, too. If lots of tiny dependencies are bundled with an app, they can’t be cached independently. If they aren’t bundled, they cost extra HTTP requests.

Maybe HTTP/2 will mitigate extra requests, but if performance is the reason for hyper-modularization, it smells premature to me. Somehow we groupthinked ourselves into fetishizing oil-rig-sized libraries before and now it’s jewlers’-screwdrivers-sized libraries. All the while we’ve been dismissing the common hammer and saw. jQuery is a set of methods for the DOM. lodash is a set of low-level language methods. These medium-sized hammers and saws won’t go away because—at a conceptual level—they’re just right.