Many things can be identified as BS simply by asking the question “What is X?”. Today, X = “framework”. First of all, what are some examples of things that have been dubbed “frameworks”? I’m sure they’ve been around for a long time, but in my mind, the mother of all frameworks is Rails. Other things that are similar enough to Rails to be called frameworks include Django, Pylons, and CakePHP. All of the examples that I’ve mentioned so far are web frameworks. But what about frameworks for things besides the web? Surely the concept can be applied more generally.
Because Rails is the hot shit, everyone else has decide you need to slap on the same label in order for your project to be cool. Exhibit A: Prototype. Let me be the first to say it: this is not a framework, just a library. Don’t get me wrong; I actually like using it, but it just isn’t a framework. At this point, you’re probably thinking I’m splitting hairs and getting frustrated with me. But if the word “framework” is to have any meaning and be at all useful, we can’t run around calling everything a framework. I think if you’re a serious engineer you should care about get things technically right, which means getting your language technically right.
On the surface, Prototype and Rails have much in common:
- They both provide basic functionality that would be useful in a wide variety of applications.
- They take out the muck that’s often associated with the type of programming where they’re meant to be used, and generally make life more fun and exciting for application programmers. For example, Prototype helps to eliminate the muck of having to deal with differences in the way JavaScript works in different browsers.
But guess what? The same thing can be said of many things that are clearly not frameworks. For example, Java provides basic functionality common to many apps, and (mostly) abstracts differences between different operating systems. In fact, anything that provides a useful abstraction would qualify under these terms.
Let’s start with what a framework is not. I claimed that Prototype is an example of this. Suppose you decide you’re going to rely on Prototype to make JavaScript programming easier in your next project. That decision does not then force your application to follow a certain structure. There’s absolutely no reason you can’t switch back and forth between Prototype’s DOM functions (such as the $$ function) and native DOM methods (such as document.getElementsByTagName). It’s also just as easy to use it with some other JavaScript library such as YUI (again, not a framework, even though it has been described as such). It might not make a whole lot of sense to be using both at the same time, because of the large overlap, but it’s quite possible to use them together effectively. For example, you might like the calendar widget in YUI, but you prefer to use Prototype for events and DOM manipulation.
In contrast, Rails forces your application to follow a particular structure. I’m not just talking about the MVC design pattern (perhaps a topic for another day), although that’s certainly part of it. I’m talking about the way Rails forces you to put your files in the right directories, and the way the framework knits those files tightly together to serve requests for dynamic web pages. For example, if your FooController has a bar method (“action” in Rails terminology), you need to have a file named bar.html.erb in your foo views directory. As for mixing Rails with something else, I’m not even sure how that could possibly work. Maybe if two parts of your site share the same model classes? Then again, your model files do not contain any of the necessary require statements that would allow them to stand-alone. Rails does that for you.
Whenever I’m trying to wrap my head around something in software, I like to try to think of analogs in physical systems. Imagine you have a complete car minus the engine and body panels. You still have the cupholder, power-windows, stearing, etc. That’s sort of what a framework is. You get to drop in your own engine, and stick on your own body panels, but you don’t get to choose your shock absorbers, stereo speakers, or which side to fill up on. Sure, you can hack these things to get them the way you want, but good luck if anything breaks and you need to bring it in for servicing.
Building a car would be very different from starting out with big pile of seats, windows, doors, air conditioners, gas tanks, etc. There are very few limits on how you combine these to make a complete car, but you might want to settle on whether you’re going to use metric on imperial units. It’s somewhat of an arbitrary decision, because there’s no reason a metric car seat cannot be married to an imperial gas tank; nevertheless, you’ll probably want to standardize on one or the other so you don’t accidentally chew up the imperial threads in your expensive engine block with a metric bolt.
The thing about libraries such as Prototype that gets people confused is that they provide basic functionality that would be useful in a wide variety of apps. In our car situation, they’re sort of like nuts, bolts, hoses, gears, and shafts. Unlike a framework, these things do not dictate the structure of your app. Although we tend to think of libraries as being more specialized, this need not be the case. A library is just a standard set of parts that you can put together in ways that need not follow a particular structure.
Now that you understand the difference between things that are frameworks and things that aren’t, I hope we can stop abusing the terminology.
allyourcode 