Silly Rabbit… Frameworks are for Prototypes

There’s a running theme on this blog, if you’ve read many of my posts. It’s that most posts come as a result of some fireshit-storm I set off on twitter or wherever else when I make a claim that almost everyone seems to disagree with. I then feel the obligatory incumbency to at least explain myself in a detailed blog post. This post is no different.

On Saturday afternoon, I tweeted:

OH “frameworks are useful only for rapid prototyping. once you go to production, you should re-write and remove the frameworks”

This came from a conversation I had with a few people, and I paraphrased a few points into that one “OH”. Someone in the conversation later corrected me that “only” should have been “most”. OK, fine, whatever.

The context of our discussion was actually about CSS frameworks, like Twitter Bootstrap. The person who made the claim was railing against the use of such frameworks in production. He claimed they were bloated (slower load due to file-size) and they were quite obviously cookie-cutter. He basically agreed that they’re very useful for rapid prototyping, but as soon as you know what the site should look like and are happy with it, you should rip out all the frameworky stuff and make custom CSS for that design.

I liked that way of putting it. I suggested the same (well, kinda) was true of JS frameworks, and the others around the circle seemed to agree.

But oh boy, did I stab some sacred cow when I dared to tweet that claim out.

Religious flame-wars aside, people really seem to love them some JS frameworks. Emberists, Angulars, Backboners, unite! Down the with heretic who dare attack our way of life!

Look…

If you like your framework, fine. I’m not trying to tell you your framework choice is wrong. That’s for another post or conf talk.

But let me say this: almost all the reasons you use to justify why using said framework even once you push code to production, are IMO silly. I’ll grant you that you like your framework-of-choice, but I’m not going to grant you anything beyond personal preference as your foundation.

What’s in a name?

It’s important that I right-away give my definition for “framework”.

A framework is an opinionated tool which exerts a strong degree of influence over how you design and architect your code, and in so doing, makes a number of assumptions about how various tasks/problems should be solved, layers on auto-magical abstractions to hide the ugly parts, and bootstraps an awful lot of the basic structure for you.


Update: I recently came up with another metaphor to depict my definition of framework, and how it fits in between “tools & libraries” and “platforms”:

  • Tools/Libraries: a geographic map you can consult on a trip (either physical folded map or app with a blinking GPS location icon).
  • Frameworks: a turn-by-turn nav system with your destination pre-entered and which is chirping out directions on where you should turn, etc.
  • (Server) Platforms (like .Net, Java, etc): a driver-less car/bus that you’re riding along in as a passenger.


jQuery/Dojo/YUI are not a frameworks. They are libraries or tools. At most, they suggest certain ideas, but they just sit there latently, unassuming, unobtrusive to your page/app, but yet provide the utilities you need should you choose to grab them from the toolbox and put them to work.

Angular, Backbone, Ember… these are frameworks. There’s an enormous and obvious difference between a project built in one versus the others.

Other people define these things differently, and find different nuances to obsess about. I don’t care. Save your breath with the nit-picking. At least you know where I’m coming from in this post.

I have absolutely no problem with tools and libraries.

I actually don’t have a problem if you even choose to use a framework… except that I don’t think you should leave a framework in place once you’re ready to go to production.

And that word “ready” is where we likely differ. Because I’d say you’re not ready if you’re still relying on a framework.

Prototyping

Frameworks are awesome for rapid prototyping. In fact, some of them were originally created for exactly such purposes.

Page 1 of 5 | Next page