A tiny nodejs module for development purposes: it parses json files and creates a server that responds to routes created on the basis of the json data, therefore simulating your real life REST api. It follows the conventions delineated on Wikipedia for Representational State Transfer and, oyez oyez, it’s stateful! So you can post or put new data and find them there at the next call. Until you restart the application, that is. There’s no database, and no external dependencies. The idea is that you use it to develop the front end while your service is not ready yet, and then you throw it away and it leaves no trace. For this very reason I’ve avoided even libraries that would have been nice to have in this particular instance, like when.js (admittedly my own version of when/parallel behaviour is, if simple, rather uncouth) and Express. But well, it’s fit for purpose and has full test coverage. Enjoy.
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 🙂
I am sure there’s a bazillion ports of Pong out there, but sometimes, as some Zen Master said once, one needs to do their own experience of something — and I had a couple of hours to spare.
It’s incredible how quick it is to write a primitive but perfectly playable game in Canvas, and how satisfying are tiny and self-contained projects.