Framework vs Library

Mon, Oct 27, 2014

Upfront, I’m going to point out that I have a horse in this race. In my experience, I’ve been bitten by gnarly, expensive code one too many times. That said, there’s been a few posts recently trying to suss out the difference between the two.

One of the pithy phrases that’s been going around:

A framework calls your code, you call a library.

This is so tempting, because it paints such a bright line. The truth is, though, the terms are ambiguous and have been used to describe such varying things in the past.

Apple uses “framework” to describe their various API groups, e.g. CoreLocation.framework, VideoToolbox.framework. C programmers have been using “library” for decades to describe the C equivalent of packages. The term “standard library” seems to mean “a lot of libraries that are part of a language distribution.” Wikipedia lists jQuery and Google Web Toolkit next to each other as Javascript frameworks. They are probably about as similar as the mercury in a thermometer and the water in Lake Superior. Sure, they’re both code for doing things on the web, but in one of them, you write almost exclusively in Java and the other just gives you some DOM and ajax tools.

We’re past the opportunity for a succinct definition for these words. A related issue, I probably read (or write) these words more often in posts deriding “frameworks” in favor of “libraries” just about as often as I read a post about a framework or library. With the current state of the field, I’m afraid I’ve come to the following conclusion:

The words “framework” and “library” are not meaningful on their own.

They both encompass “a distinct codebase you use from a project to avoid work duplication or to simplify a problem.” Perhaps you’ll say, “but they have different shades of meaning,” and perhaps they do to you. Just like the terms “web scale,” or “object-oriented^1.,” or “the cloud,” they just aren’t specific enough. Write better than that; either avoid them or qualify them.

Now I don’t want to just leave you hanging, and as I said, I do have my stake here. Let’s take another look at some ideas people describe when they smack-talk “frameworks,” however, my critique here is just as valid for something called a “library.” Think of a common code dependency you like or dislike and answer these questions:

• Does it hide details about underlying actions in a way that makes it difficult for you to uncover them?
• Does it hide details about underlying data in a way that makes it difficult for you to compose its functionality with that of a similarly purposed “framework” or “library”?
• Does it lead to difficult to understand stack traces?
• Does it require a substantial amount of specific code (including configuration or subclasses) before it is useful?
• Does it require you to force your program’s structures or types into a pattern they don’t mesh with fluidly?
• Does it reduce the safety of your code?
• Does it make your code difficult to reason about?
• Does it limit your ability to provide features using patterns it doesn’t support?
• Does it encourage your own code to conflict or race with itself?

Great. Now consider the combined penalty of those “yes” answers. Other questions you can ask:

• How much are you gaining from this library?
• Is there another framework that could be a reasonable alternative?

These are the kinds of questions you can use to think about the quality of a project, rather than “is it a framework or library?” Because those words say nothing more than the fact it is a project, when you’re writing about it, let’s use words like the following to describe projects that answer “yes” to the above questions:

• expensive, ill-fitting, lossy, opaque, rough, encumbering, high-touch, gnarly, captive

and these to code that answers “no”:

• thrifty, frugal, tailored, concise, transparent, precise, straightforward, honest, agreeable, detachable

These are just some ideas. I’m looking forward to reading some well-worded reviews and critiques.