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.
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.
Please feel free to fork breve.js and remove stuff from it 🙂