When to Use and When Not to Use Frameworks
Saturday, 17th March 2012, 13:59

Back when I started coding, a long time ago in a galaxy far, far away, there was no such thing as a framework. Heck we were just getting used to the idea of a library, and even then all that meant was a collection of routines written down on a piece of paper somewhere you could re-use if you hadn't lost it.

As devices became more complicated, and in a large part thanks to the proliferation of the C language, libraries became the norm. Why reinvent the wheel every time when you could just include one you had lying around already, even if it did come with a load of other wheels you'd never use and dragging a cart behind it.

This made the act of coding quicker, if pushing up memory usage towards the ridiculous levels we see today, and it wasn't long before frameworks appeared, which are really just glorified libraries or collections of libraries, which wrap around the task in hand and shield you from the complexity of it all. That brief preface brings us neatly up to now.

Have Frameworks Replaced the Art of Programming?

Ah... BASIC. Pretty much every machine came with it many moons ago.

You know what made BASIC so good back in the 80s? The language shielded you from the complexities of actually dealing with the hardware your code ran on. Bad implementations aside, it let a lot of people get into programming who otherwise would never have, because it lowered the entry barrier.

You know what made BASIC bad? It shielded you from the complexities of actually dealing with the hardware your code ran on. If your computer was a car, BASIC would be the guy sitting in the back barking instructions at you with no real understanding of how to drive.

In some respects, frameworks are a similar beast. People who have no business programming, are being paid to program when all they can really do is back seat drive via a framework. They don't understand how the framework actually works, they just know how to bark orders at it.

That's fine and all, it can get you from A to B, just not always by the best most efficient and safest route.

How to Tell a Good Programmer From a Bad Programmer

This is a rough, unscientific litmus test, but I think it probably works...

A good programmer is one who uses frameworks when they are the best tool for the job, uses only ones appropriate for the task in hand, and if there isn't one that suits the job well enough, chooses not to use them, or writes their own.

A bad programmer always uses frameworks, and wouldn't know when to begin with writing their own.

So When Should You Use Frameworks?

The answer was above, when it is the best tool for the job.

Yes, it's that easy.

Sometimes that means the quickest way to do the job, other times it means the fastest way the job happens when its finished. But it should never be simply because it is the easiest way to do the job.

Let's take jQuery as an example. Whilst described as a library, it is what these days people would call a framework. And a good one at that, but why is it? Often much you can do with it can be done in other ways, it isn't the only client side DOM framework, and not the leanest or fastest.

But it provides an easy, and most importantly, cross browser method for interacting with the Document Object Model in a friendly and easy to use manner. And it supports a very simple plugin architecture that lets you extend it almost any way you like.

You could write portions of it yourself, but that would take a lot of time, and an amount of cross-browser testing which is beyond any individual with limited time on their hands. So, using jQuery is good, and so is probably using a similar equivalent framework for interacting with the DOM that does the job you want from it.

For similar reasons, I use the Connect framework for Node.js, because it allows the quick addition of middleware components relating to session management, cookies, forms, serving static elements, gzipping downloads, etc, that are very useful and save me time in maintenance.

I don't however use Express for Node.js, because every time I look at it I see a lot of duplication when it comes to Connect features (yes I know it sits on top of Connect) and I don't feel it adds anything I want to use.

For me, Node.js is about speed, and I'm willing to sacrifice some of it for the advantages Connect gives me, but not Express. I'm not saying some people may find Express useful, merely saying that I don't see what it brings to my party, and it's my party and I'll framework if I want to.