“Can everyone stop writing JS micro-libraries for a second. I need to catch my breath.”1
There are a few posts (on both sides of the fence) about this shit-storm2 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…
The short version:
- A “micro-framework” (roughly defined) is a tiny library, laser-focused on solving one problem3;
- 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 framework4) 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 dubious5; 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.6 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
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?7)
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/
- Apologies to Angus Croll. From whom I totally stole that. [↩]
- Not that I’m not telegraphing my own feelings on the subject with that bit of color but… [↩]
- …or very small, very specific set of problems… [↩]
- 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. [↩]
- 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. [↩]
- Especially that whole “100% of sites aren’t using 100% of the available features” statistic. [↩]
- 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. [↩]