found drama

“Can everyone stop writing JS micro-libraries for a second. I need to catch my breath.” ¹

There are a few posts (on both sides of the fence) about this shit-storm ² of “micro-frameworks” that seem to be getting announced every other day lately; and while I’m not sure if the following referenced post is the best post on the subject, it’s certainly the one that resonated with me the most…

Yesterday, Tom Dale wrote a post on his blog entitled “Imagine a Beowulf Cluster of JavaScript Frameworks”; a snip:

Here’s the reality: As web applications get more complex, developers end up needing all of the miscellaneous nuts and bolts that they thought they would never use. Take Flow for example. Flow is a killer task manager web application built on Backbone.js. Backbone.js often advertises that it is only 3.9kb minified and compressed. How much of Flow’s nearly 900k of (minified!) JavaScript do you think is the application developers filling in the deficiencies in Backbone?

The short version:

1. A “micro-framework” (roughly defined) is a tiny library, laser-focused on solving one problem ³;
2. you (as a JavaScript developer) are then free to mix-and-match these otherwise unencumbered “micro-frameworks” as you see fit to solve your specific problem(s) in your specific application(s);
3. your (presumptive) benefit is that you get a lot of flexibility, while loading only the JavaScript that you need, (presumably) saving you overhead;
4. and/but then you have to worry about integrating all of the little bits of all of the little micro-frameworks together, trusting that they’re sufficiently sandboxed to avoid identifier and naming collisions (to start with the obvious) and hoping that they don’t otherwise just cause you unnecessary thrash.

Dale makes the argument that (more often than not) the conventional wisdom of using a larger framework (in the more classical sense of a framework ⁴) is the way to go. His argument seems to be largely predicated on two points: (1) that even if you’re not using all the features to begin with, as your app grows, its requirements grow, and sooner or later you’re using everything-or-close-to-it; and (2) that the larger frameworks are better vetted, with longer histories and more people behind them, and bigger communities, etc.

The second point is a bit dubious ⁵; giving them the benefit of the doubt, and assuming that the authors of the so-called micro-frameworks are serious and are in it for the long-haul, then it’s just a matter of time before a few of them earn some street cred. (And, arguably, some are already.)

Dale’s first point is more/less in direct response to Thomas Fuchs’ assertion that most sites don’t use most of the features provided to them by the libraries that they have deployed to production. It’s hard to disagree with that. ⁶ Still, maybe those developers are just getting warmed up; or maybe there’s nothing at all wrong about using not-100% of your chosen library’s features when you’re using a sufficient percentage of the remainder.

And hopefully you put some good long/hard thought into the framework before you checked in that first <script src="..."> into your repo but either way, there is something else to be said about using a framework, something that goes beyond what is strictly technical, but something that is no less important: idiomaticity. When you adopt a framework, you are also adopting the way of thinking about your problem domain. Maybe you had the way thought-out already and you just happened to find a framework that fit with the way; or perhaps the framework helped you break past some mental block and showed you the way that would work best. But the framework is going to do more for your team than just normalize event delegation in different browsers – it is also going to give you some focal points, some reliable methods and predictable properties, the starting points for a shared nomenclature and some other basic conventions. It’s going to shape that shared and version-controlled conversation; it may be “just JavaScript” but sometimes it’s comforting (and thus more productive) to know you don’t need to re-invent every idiom.

Which isn’t to say that the way of the framework should necessarily dictate the way that your team thinks best (we all need those kinds of disagreements and nit-pickery), but why not let it (the framework) save a few headaches? (Wasn’t that the whole point to begin with? ⁷)

And that seems to be one of the biggest things missing from the micro-framework discussions that I’ve seen thus far. Sure you can pick and choose, and maybe you’ll save a few kilobytes (possibly at the cost of caching?) – but aren’t you then just trading one problem for another? If you start out with a large library, you can worry less about where to look when you have some new problem – you know you (and/or someone on your team) will look first to the framework that you’re all already using. If you’ve cobbled together a bunch of micro-solutions from micro-frameworks, it stands to reason that it becomes harder to know where to start. And perhaps that works just fine for a small team; but how large does a team get before the left and right hands have trouble talking?

Which is not at all to suggest that the problems are unsolvable.

But as a few folks hat-tip in the comment thread on Dale’s blog: carefully choose the right tool(s) for the job.

UPDATE: (12/23/2016) A reader has pointed out to me that the link with the text “Backbone.js” in the Tom Dale quote has since gone dead. Originally it linked to the Backbone.js documentation. As this has moved, I am including the updated link here: backbonejs.org/

1. Apologies to Angus Croll. From whom I totally stole that.[↩]
2. Not that I’m not telegraphing my own feelings on the subject with that bit of color but…[↩]
3. …or very small, very specific set of problems…[↩]
4. And by “classical sense” here I mean: a large-ish library or framework designed to solve a constellation of problems, not just one specific laser-focused thing.[↩]
5. I’ll also admit that I’m pulling a bit of an inversion with #2. Taken on their face, Dale’s comments are more about how the micro-frameworks are new and very specific; but it isn’t too much of a stretch to see that as indicting the micro-frameworks in favor of the larger libraries.[↩]
6. Especially that whole “100% of sites aren’t using 100% of the available features” statistic.[↩]
7. Now is probably a good time to throw out the disclaimer that you should still do the responsible thing and get intimate with your chosen framework. Seriously, you may love that you never have to solve problem X because feature Y in framework Z takes care of that; but you’d be wrong – sooner or later you’ll hit the limit and have to take a deep dive into the un-minified private nether regions of your favorite framework. And there are some haunting quirks out there, let me assure you of that.[↩]

About Rob Friesel