The Philosophy of Modular Code & Planning for Obsolescence

The other night I was listening to Jed Watson giving a talk about Keystone and he mentioned something that I had been thinking about lately and voiced a particular opinion on the subject that I strongly agree with. That subject was modularity, and the particular hypothesis/observation is what I will try to describe in this post.

Modularity, or perhaps more accurately “Extreme Modularity”, has been a hot topic of late in the Javascript world. Sindre Sorhus wrote about how he was all for the creation and use of modules that might be as small as a one-liner. Many applauded this, some wondered whether it might be taking things too far and others disagreed. e.g. Rich Harris who argued that these “nano-modules” were of more benefit to package producers such as Sorhus than package consumers.

Nevertheless, putting this debate aside for the moment, the Javascript/Node/npm community is one that strongly advocates for a modular philosophy. While there is a great deal of common ground in terms of what most modern developers of any persuasion would consider to be good practice there are also differences that cut across communities. Just as the Ruby community smiles upon “magic” the Python community frowns upon it. These differences don’t necessarily correspond to one community thinking the other is wrong either — they sometimes just reflect the acceptable idioms of the language.

At any rate the insight Jed managed to articulate is that, while modularity is more or less universally considered desirable — the Javascript community truly embraces it. And this is important because while modularity in code itself might be important — a philosophy of modularity is arguably much more important.

Philosophy vs Code

What could this mean? One example springs to mind. Ember lead developer Erik Bryn has sometimes complained that people misconstrue Ember as being a monolithic framework. As he explained the code was all very modular and there was nothing stopping you from using one part and not another, except perhaps for a lack of documentation.

At this point I’d say — put your hands up if you are using bits and pieces of Ember? I’d be willing to bet that 99% of Ember developers buy into the whole package so to speak — because thats the Ember philosophy. Ember is built to manage your entire front end — with the hope being that this cuts through a lot of discoverability and compatibility issues and “just works”.

It of course comes from the Ruby on Rails world and shares similar philosophies of “convention over configuration”. From seeing Yehuda Katz speak about Ember in Sydney a few years ago one definitely sensed a disdain for what he saw as the typical Javascript’s developers desire to do things their own way.

What this means is that while Ember (or Rails for that matter) may be built in a modular fashion for all intents and purposes they are monolithic framworks because thats how everyone uses them — philosophy matters. Thats why Ember’s response to React was to rewrite its own View rendering layer to be more React-like — Ember is a framework, and its designed to be used as such. As Bryn himself said when arguing against the idea of Ember as a monolith: “I consider it a failure if someone felt the need to swap things out”

Truly Modular Tools Are Ready for Obsolescence

Modern Javascript is famous for its Cambrian explosion of tools and packages and the frightening speed with which one particular species can become extinct and be replaced by a newer, fitter (and of course, hipper) competitor. The switch from Grunt to Gulp and RequireJS to Browserify in particular have been much commented on and one could similarly marvel at the rise of React, Webpack & Redux.

This can be as much a source of frustration as amazement — perhaps it would be preferable if a new tool had to delete an old one from the npm registry Highlander style — “there can be only one.”

“Sorry old friend — this package registry is only big enough for the one build tool…”

On the other hand its the great strength of the javascript philosophy and I would argue something that people should keep in mind when developing trying to develop new packages.

I think it goes without saying that anyone who throws their hat in the ring by releasing a new package/tool/framework wants as many people as possible to use their package. Perhaps early success more than anything else tempts some to expand the scope of their project, to try and grab more mindshare, more stars on Github etc. To become an indispensable and beloved part of every smart developers toolset.

However this nullifies one of the great advantages of small modules — disposability. A dependency that you depend on to a limited extent has the virtue of being relatively painless to replace. If that hip new library that everyone will be talking about tomorrow is actually useful, if it offers a genuine competitive advantage then its a much less daunting task to add it to your current project if you havent already married yourself to a honking big framework that wants to own your whole stack.

For that reason, one could argue that a responsible developer doesn’t seek immortality for their creation. Instead they should be aiming for something closer to a planned and painless obsolecence. A good package leads a quiet life, minds its own business, and, when it inevitably passes on, leaves the place nice and tidy for the new tenant to move in.

The King is Dead — Long Live the King.

Like what you read? Give Hal Henke a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.