The bloat. Oh, how it irritates me.
I feel quite lonely in this. Yes, we compete over concision, can you write a state machine in 148 characters dude?, we try to keep the footprint of libraries within reasonable boundaries — but then we think nothing of including, dunno, lodash.js because in our project we use once .reduce and twice .map.
jQuery is a particular victim/accomplice in this: we add it without a second thought, even before we ascertain if it’s needed or not. Heck, we take for granted that we are going to need it at some point.
JQuery, Backbone, require and underscore/lodash: the bog standard frontend stack as of…hmm, last year? We include it in the space of a breath, offhandedly, without thinking.
Don’t take me wrong: they are wonderful tools. I especially love underscore/lodash. It’s expressive, and concise, and just damn useful. In fact, it’s so nice to have that we tend to use it all the time. Just in case.
And don’t get me started on what happens on the Node side. Express and Jade – lovely, lovely modules by the way – get usually required on the spot, followed by dozens of others of which we usually utilise 10% or less of the actual capabilities. Freed even from the concern of bandwidth occupation, we think there’s always time to remove. And we never remove anything, anyway.
But, you will ask (please do ask), what’s wrong in this? Module footprint is not a problem in node, and it’s less and less of a concern on the desktop. We are a bit fussed on mobile, and we look for smaller libraries for mobile orientated stuff (but the erosion has started there too… the first philistines objecting: but a lot of the times those mobile devices are used through wi-fi… jaja). On the whole, contending for not-so-scarce connectivity resources with bandwidth-hogging images, html, css, cookies and whatsnot, our concatenated, minified and compressed javascript files have a clean, light conscience, even with the odd one or two superfluous kb.
Still, the bloat is bad, in my honest but humble, please-don’t-troll-me opinion.
It’s a question of mental order. Un-utilised and under-utilised resources are, for all intent and purposes, a broken window. One of these famous broken windows that rot uses to gain access and fester. We don’t want broken windows. We want code that it’s un-broken-windowed, so squeaky clean that it’s almost antibacterial. Reducing the bloat increases cleanliness and order.
It’s a question of maintenance. We assume that whoever will maintain our code will know by heart every quirk and feature of our favourite browser stack, but this is seldom the case if we deviate from whatever is the cultural norm or fashion during the lifetime of the product (Spring/Summer 2013 will see the classic Mootools make a comeback..). This might be an argument for limiting the use of non-mainstream libraries, but we might not like the more traditional options, we might want to try something new… and we condemn our successor to be recruited through one of those unloving “Needs commercial experience of RandomObscureLibraryThatSeemedAGoodIdeaAtTheTime“. Less bloat means to incorporate abstractions in a manner that is (hopefully) more integrated to the fabric of our project. It means that our custom “extend” will have to be acknowledged and remembered, but not alongside several showelfuls of unused accompanying methods.
And, I don’t know you, but I really don’t like to learn new APIs if they don’t offer an alternate view on the traditional ways to accomplish an operation.
So, inspired by the brilliant http://youmightnotneedjquery.com which shows us how vanilla javascript is often all what we need, I’ve put together a collection of the methods that I use for quick, small toy projects: breve.js. It includes extend, mixin, custom event and very little else. I was tempted to leave it un-AMDfied to further reinforce the idea that, in reality, we need very little to weave our code, but then I relented because almost no project nowadays does without modular loading. I have also added a polyfill for requestAnimationFrame because the browser support is prodigiously limited, and I might add promises soon, although naked callbacks are seldom a problem in the kind of tiny projects breve.js is meant to be used in.
Please feel free to fork breve.js and remove stuff from it 🙂