What's the difference between a library and a framework?

The simple answer to this one is: you call a library, but a framework calls you. Let's explain that by analogy, also touching briefly on what it means from a programming perspective.

Imagine you work as a developer for a Software House. Every day you have to translate the client Requirements analysis into code in front of your notebook, making programs. But you still have to follow the Software design, and the software architect is your boss.

The boss provides you a SDK to act within. The application should have a specific architecture and must be built with that toolkit. This is programming with a framework: you have not the freedom to choose WHAT tools you have to use, only HOW to use it.

One day, you get promoted. You're excited, this is your time to shine and show the world your vision! Of course, with power, comes responsibility. Maybe you direct a box office hit. Or maybe, everything falls to pieces, because it turns out you didn't know as much about directing (or managing) as you thought you did?

This is programming with a library: you have more freedom to design how the system works, how everything will connect together; but with that freedom, comes more responsibility and even more risk. You might think you're a great architect, only to have the house of cards fall down on you when things get serious and the code-base grows.

In programming, it always comes down to one thing: choosing the right tool for the job. Programmers are faced with many tools. Too many. Have you heard the expression "paradox of choice"? That sums up the IT world. The "shall we build our application with a library or a framework?" is just one of many decisions facing us, but it can be an important one. A team with many junior developers may be better off with a framework, enforcing structure and standards, telling them how to build the app; an application that's not run-of-the-mill and has niche functionality might work better if a library is used, to allow greater flexibility and control. - Dave Clayton

The most important difference, and in fact the defining difference between a library and a framework is IoC (Inversion of Control). Quoting Martin Folwer in his article on Inversion of Control:

Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client. A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

What does this mean? Well, it means that when you call a library, you are in control. But with a framework, the control is inverted: the framework calls you. (The Hollywood Principle: Don't call Us, We'll call You.) This is pretty much the definition of a framework. If it doesn't have Inversion of Control, it's not a framework.

Basically, all the control flow is already in the framework, and there's just a bunch of predefined white spots that you can fill out with your code. On the other hand, a library is a collection of functionality that you can call.

Another good explanation comes from Gang of Four's book 'Design Patterns, Elements of Reusable Object Oriented Software', the Holy Bible for every good software developer. Here are the definitions of Toolkit and Framework:

Often an application will incorporate classes from one or more libraries of predefined classes called toolkits. A toolkit is a set of related and reusable classes designed to provide useful, general-purpose functionality. Toolkits don't impose a particular design on your application; they just provide functionality that can help your application do its job. They let you as an implementer avoid recoding common functionality. Toolkits emphasize code reuse. A framework is a set of cooperating classes that make up a reusable design for a specific class of software. The framework dictates the architecture of your application. It will define the overall structure, its partitioning into classes and objects, the key responsibilities thereof, how the classes and objects collaborate, and the thread of control. A framework predefines these design parameters so that you, the application designer/implementer, can concentrate on the specifics of your application. The framework captures the design decisions that are common to its application domain. Frameworks thus emphasize design reuse over code reuse, though a framework will usually include concrete subclasses you can put to work immediately. Reuse on this level leads to an inversion of control between the application and the software on which it's based. When you use a toolkit (or a conventional subroutine library for that matter), you write the main body of the application and call the code you want to reuse. When you use a framework, you reuse the main body and write the code it calls. You'll have to write operations with particular names and calling conventions, but that reduces the design decisions you have to make. Not only can you build applications faster as a result, but the applications have similar structures. They are easier to maintain, and they seem more consistent to their users. On the other hand, you lose some creative freedom, since many design decisions have been made for you.

If applications are hard to design, and libraries/toolkits are harder, then frameworks are hardest of all. A framework designer gambles that one architecture will work for all applications in the domain. Any substantive change to the framework's design would reduce its benefits considerably, since the framework's main contribution to an application is the architecture it defines. Therefore it's imperative to design the framework to be as flexible and extensible as possible.

Frameworks are becoming increasingly common and important. They are the way that object-oriented systems achieve the most reuse. Larger object-oriented applications will end up consisting of layers of frameworks that cooperate with each other. Most of the design and code in the application will come from or be influenced by the frameworks it uses.

To resume all:

• Library: code reuse => you call the code

• Framework: design reuse => the code calls you (IoC)

P.S. I also suggest reading this article: Do Not Learn Frameworks. Learn the Architecture (intentionally provocative). Nowadays frameworks have certain advantages, but still, they cultivate ignorance.