Library vs. Framework
You call a library, but it’s the framework that calls you. The difference is inversion of control.
Let’s play a little game:
- React: library or framework? ➡️ Library.
- Jest: library or framework? ➡️ Framework.
- Express: library or framework? ➡️ Framework.
If this leaves you puzzled, read on.
The difference: which calls which
A matter of size? Hmmm, not really. There are small frameworks and very large libraries. And then, well, the size… you know what I mean.
So what is it, then?
Wikipedia suggests that a “framework differs from a simple software library primarily, on the one hand, by its generic, weakly specialized nature, unlike certain libraries;” No, I didn’t truncate that sentence. Once you put the words back in order, you’ll agree with me that the substance is debatable. Counterexamples abound, starting with React.
Further on, the same article states that “[the framework] imposes a working framework that guides software architecture and even leads the developer to adhere to certain design patterns.” Now that’s true, and we’ll come back to it.
By the way, let’s get back to that right away.
In fact, what characterizes a framework is inversion of control (IoC). This time, Wikipedia does a good job of defining the concept:
Inversion of control […] works on the principle that a software’s execution flow is no longer under the direct control of the application itself but rather under the control of the framework or the underlying software layer.
Keep in mind that when you’re auditioning in Hollywood or going for a job interview in Issy-les-Moulineaux, you’re, like Monsieur Jourdain, practicing “inversion of control” without even realizing it: “Don’t call us, we’ll call you.”
Example: a test runner
I realize this might still seem abstract, so let’s take a very simple example created for this purpose:
https://github.com/mathieueveillard/library-vs-framework
A rudimentary test runner, in the form of a library. Two methods, expect.equal and displayTestResult, which can be called as follows:
displayTestResult("This test succeeds", expect.equal(0, 0));
But it might be a shame to lay bare the inner workings of the library like this, since it requires me, the developer, to already have some understanding of how it works.
Hence the idea of creating a framework “on top of” the library, that is, one that uses it. The framework, though microscopic, is a full-fledged framework because it implements inversion of control. To take this exercise to its logical conclusion, we decide to pass the expect function as an argument to the test scenario:
test("This test succeeds", (expect) => { expect.equal(0, 0); });
Pros and Cons
Ultimately, why create a framework rather than a library?
A framework is there to chart your course, to let you move forward without constantly wondering where to go: the direction is dictated to you. This is very useful for helping less experienced people get started and allowing you to produce a robust, high-quality result in under an hour. This explains, in particular, the success of AngularJS in the corporate world at a time (~2010) when almost no one in the software industry had the skills needed to cleanly code a Single Page Application.
The corollary is that it’s difficult to stray from the path already laid out. Over time, the most experienced developers may feel constrained, or even be forced to develop workarounds to compensate for the framework’s limitations. That’s why, over time, React has regained market share.
Frameworks are fully justified in certain cases—I’m thinking specifically of Jest. But as we know, you shouldn’t overdo a good thing.