The difference between frameworks and libraries

In software engineering we often reuse code. There is even a Clean Code principle called Don’t Repeat Yourself (DRY) which is encouraging code reuse. Frameworks and libraries are not written to solve a distinct or unique problem. They are written to be reused in specific cases and that way solve thousands and millions of problems. Let us take a look at both of them and discuss the difference.

Libraries

A library is a piece of code that ships in a decent format to be integrated into other programs. Instead of kicking off a main function it usually provides classes and/or functions that can be used by your application. Libraries solve reoccurring problems that are usually super annoying and complicated. Examples are parsing stuff (JWT, JSON, XML, date formats, command line arguments), utilities, or specialized data structures. A library knows the details and in a way you ask it for an answer to a question.

The critical observation here is this: Your code orchestrates the library. When using a library in your code you have to mention its name (I will call that a compile time dependency even if you use a dynamic language) and you will have to call one its functions and they will return. At runtime your code calls into the library.

Frameworks

Frameworks and libraries are very similar in that frameworks also solve annoying, complicated, and reoccurring problems — but they differ in their approach. A framework always does something. It does something where it ultimately does not know the answer to and needs your help in form of a plugin. The plugin provides the details.

A classic example is a web framework: Web frameworks spin up a server listening on a given port, probably deal with TLS, parse HTTP messages coming in, looking for markers like host-names, paths, and then try to handover control to a plugin — which has to come from you. By using a framework you reuse a ton of code so you do not have to deal with all that jazz around dealing with HTTP messages and can focus instead on defining the answer to that web request — or in framework terms: you can focus on writing a plugin (we often call this “controller”).

The framework needs a way to call the plugin without knowing its specific name. Often (not always), you need to implement one of the frameworks interfaces, e.g. an void handle(HttpRequest request, HttpResponse response) method and then tell the framework when to use this implementation.

In my experience every framework works somewhat like this:

1. Write a plugin
2. Register the plugin with the framework
3. Transfer control to the framework

The critical observation here is this: The framework orchestrates your code. When using a framework you have to mention its name for initialization and configuration, so again you have a compile time dependency. But once you transfer control to the framework it (usually) does not return. Because the framework starts doing its thing.

And that’s the difference

When using a library, at runtime, your code is calling into the library. When using a framework, at runtime, the framework is calling into your code (via plugins).

When talking about frameworks we often refer to this concept as Inversion of Control (IoC), as the flow of control opposes the compile time dependencies.

Encore

This concept can also be used on a much smaller scale. Imagine you have some code with lots of branches:

void handle(String status) {
  switch (status) {
    case "ALL_GOOD":
      green(); break;
    case "NEEDS_ATTENTION":
      amber(); break;
    case "CRITICAL":
      red(); break;
  }
}

You could instead create implementations of an interface Handler and map them to a Status in a Map<String, Handler>, then lookup the handler, and just call it:

statusHandlers.put("ALL_GOOD", greenHandler);
statusHandlers.put("NEEDS_ATTENTION", amberHandler);
statusHandlers.put("CRITICAL", redHandler);
statusHandlers.get(status).handle();

This style is also known as if-less programming and is an example of the Open-Closed-Principle (OCP).