10 Answers
10

The most important difference, and in fact the defining difference between a library and a framework is Inversion of Control.

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. (This is called 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. (I'm looking at you, .NET!)

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.

A library on the other hand is a collection of functionality that you can call.

I don't know if the term toolkit is really well defined. Just the word "kit" seems to suggest some kind of modularity, i.e. a set of independent libraries that you can pick and choose from. What, then, makes a toolkit different from just a bunch of independent libraries? Integration: if you just have a bunch of independent libraries, there is no guarantee that they will work well together, whereas the libraries in a toolkit have been designed to work well together – you just don't have to use all of them.

But that's really just my interpretation of the term. Unlike library and framework, which are well-defined, I don't think that there is a widely accepted definition of toolkit.

Well, you've given a good point, but don't you think that Hollywood's law is related to application workflow and DI (IoC) is related to dependency resolving process? I mean that all frameworks do follow the Hollywood Law (by definition) but not every (I would even say more of them) don't care of dependencies resolving. Don't you agree?
–
zerkmsFeb 13 '11 at 5:37

1

And also you mentioned .net --- it hasn't any built in DI containter, that is why .net developers use ninject or castle windsor. So .net is not a framework then?
–
zerkmsFeb 13 '11 at 5:39

Martin Fowler discusses the difference between a library and a framework 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.

To summarize: your code calls a library but a framework calls your code.

There are various terms relating to collections of related code, which have both historical (pre-1994/5 for the purposes of this answer) and current implications, and the reader should be aware of both, particularly when reading classic texts on computing/programming from the historic era:

Library: Both historically, and currently, a library is a collection of code relating to a specific task, or set of closely related tasks which operate at roughly the same level of abstraction. It generally lacks any purpose or intent of it's own, and is intended to be used by (consumed) and integrated with client code to assist client code in executing it's tasks.

Toolkit: Historically, a toolkit is a more focussed library, with a defined and specific purpose. Currently, this term has fallen out of favour, and is used almost exclusively (to this author's knowledge) for graphical widgets, and GUI components in the current era. A toolkit will most often operate at a higher layer of abstraction than a library, and will often consume and use libraries itself. Unlike libraries, toolkit code will often be used to execute the task of the client code, such as building a window, resizing a window, etc. The lower levels of abstraction within a toolkit are either fixed, or can themselves be operated on by client code in a proscribed manner. (Think Window style, which can either be fixed, or which could be altered in advance by client code.)

Framwork: Historically, a framework was a suite of inter-related libraries and modules which were seperated into either 'General' or 'Specific' categories. General frameworks were intended to offer a comprehensive and integrated platform for building applications by offering general functionality, such as cross platform memory management, multi-threading abstractions, dynamic structures (and generic structures in general). Historical general frameworks (Without dependency injection, see below) have almost universally been superseded by polymorphic templated (parameterised) packaged language offerings in OO languages, such as the STL for C++, or in packaged libraries for non-OO languages (guaranteed Solaris C headers). General frameworks operated at differing layers of abstraction, but universally low level, and like libraries relied on the client code carrying out it's specific tasks with their assistance.

'Specific' frameworks were historically developed for single (but often sprawling) tasks, such as "Command and Control" systems for industrial systems, and early networking stacks, and operated at a high level of abstraction and like toolkits were used to carry out execution of the client codes tasks.

Currently, the definition of a framework has become more focussed and taken on the "Inversion of Control" principle as mentioned elsewhere as a guiding principle, so program flow, as well as execution is carried out by the framework. Frameworks are still however targetted either towards a specific output; an application for a specific OS for example (MFC for MS Windows for example), or for more general purpose work (Spring framework for example).

SDK:"Software Development Kit": An SDK is a collection of tools to assist the programmer to create and deploy code/content which is very specifically targetted to either run on a very particular platform or in a very particular manner. An SDK can consist of simply a set of libraries which must be used in a specific way only by the client code and which can be compiled as normal, up to a set of binary tools which create or adapt binary assets to produce it's (the SDK's) output.

Engine: An Engine (In code collection terms) is a binary which will run bespoke content or process input data in some way. Game and Graphics engines are perhaps the most prevelant users of this term, and are almost universally used with an SDK to target the engine itself, such as the UDK (Unreal Development Kit) but other engines also exist, such as Search engines and RDBMS engines.

An engine will often, but not always, allow only a few of it's internals to be accessible to it's clients. Most often to either target a different architecture, change the presentation of the output of the engine, or for tuning purposes. Open Source Engines are by definition open to clients to change and alter as required, and some propriety engines are fixed completely. The most often used engines in the world however, are almost certainly Javascript Engines. Embedded into every browser everywhere, there are a whole host of JavaScript engines which will take javascript as an input, process it, and then output to render.

API: "Application Programming Interface": The final term I am answering is a personal bugbear of mine: API, was historically used to describe the external interface of an application or environment which, itself was capable of running independently, or at least of carrying out it's tasks without any necessary client intervention after initial execution. Applications such as Databases, Word Processors and Windows systems would expose a fixed set of internal hooks or objects to the external interface which a client could then call/modify/use, etc to carry out capabilities which the original application could carry out. API's varied between how much functionality was available through the API, and also, how much of the core application was (re)used by the client code. (For example, a word processing API may require the full application to be background loaded when each instance of the client code runs, or perhaps just one of it's linked libraries; whereas a running windowing system would create internal objects to be managed by itself and pass back handles to the client code to be utilised instead.

Currently, the term API has a much broader range, and is often used to describe almost every other term within this answer. Indeed, the most common definition applied to this term is that an API offers up a contracted external interface to another piece of software (Client code to the API). In practice this means that an API is language dependent, and has a concrete implementation which is provided by one of the above code collections, such as a library, toolkit, or framework.
To look at a specific area, protocols, for example, an API is different to a protocol which is a more generic term representing a set of rules, however an individual implementation of a specific protocol/protocol suite that exposes an external interface to other software would most often be called an API.

Finally: As noted above, histoic and current definitions of the above terms have shifted, and this can be seen to be down to advances in scientific understanding of the underlying computing principles and paradigms, and also down to the emergence of particular patterns of software. In particular, the GUI and Windowing systems of the early nineties helped to define many of these terms, but since the effective hybridisation of OS Kernel and Windowing system for mass cunsumer operating systems (bar perhaps Linux), and the mass adoption of dependency injection/inversion of control as a mechanism to consume libraries and frameworks, these terms have had to change their respective meanings.

Hope this helps.

p.s. After thinking carefully about this subject for over a year I reject the IoC priciple as the defining difference between a framework and a library. There ARE a large number of popular authors who say that it is, but there are an almost equal number of people who say that it isn't. There are simply too many 'Frameworks' out there which DO NOT use IoC to say that it is the defining principle. A search for embedded or micro controller frameworks reveals a whole plethora which do NOT use IoC and I now believe that the .Net language and CLR is an acceptable descendant of the "general" framework. To say that IoC is the defining characteristic is simply too rigid for me to accept I'm afraid, and rejects out of hand anything putting itself forward as a framework which matches the historical representation as mentioned above.

For details of non-IoC frameworks, see, as mentioned above, many embedded and micro frameworks, as well as any historical framework in a language that does not provide callback through the language (OK. Callbacks can be hacked for any device with a modern register system, but not by the average programmer), and obviously, the .net framework.

A library is simply a collection of methods/functions wrapped up into a package that can be imported into a code project and re-used.

A framework is a robust library or collection of libraries that provides a "foundation" for your code. For example, the .NET framework is a large collection of cohesive libraries in which you build your application on top of. You can argue there isn't a big difference between a framework and a library, but when people say "framework" it typically implies a larger, more robust suite of libraries which will play an integral part of an application.

I think of a toolkit the same way I think of an SDK. It comes with documentation, examples, libraries, wrappers, etc. Again, you can say this is the same as a framework and you would probably be right to do so.

They can almost all be used interchangeably.

** UPDATE: ** As seen in the comments by Jorg and other posters, a framework follows an Inversion of Control pattern. I stand corrected in my interpretation of a framework.

@Jorg - Inversion of Control is a design pattern. What does that have to do with a framework?
–
Jordan ParmerJun 17 '10 at 13:27

@Pascal - I know and I qualified in my answer that it is more of an "implication" than a fact. Frameworks can indeed be small. As a developer, my brain thinks of the word "framework" as being more of a suite than a "library" that might provide a very focused set of methods. Just implied connotation is all I mean.
–
Jordan ParmerJun 17 '10 at 13:30

4

Inversion of Control is the defining difference, and in fact pretty much the only difference between a library and a framework. Both a library and a framework are a collection of functionality. The only difference is who is in control. With a library, your code is in control and calls the library. With a framework, the control is inverted: the framework is in control and it calls your code. Not mentioning Inversion of Control when explaining the difference between a framework and library is like not mentioning breathing when explaining the difference between a whale and a fish.
–
Jörg W MittagJun 17 '10 at 13:43

-1: You are missing the most important difference between a library and a framework: Inversion of Control.
–
Jörg W MittagJun 16 '10 at 23:07

1

I don't know Jorg - I think the term framework has been around for longer than IOC has been in common use. Framework may imply IOC but IMO does no necessitate it.
–
GrokyJun 17 '10 at 0:13

1

@Groky: I'm not sure. I have seen frameworks that are older than me for machines produced by companies that no longer exist, and they use Inversion of Control. Heck, every .*rc file in Unix is an example of IoC. Hook scripts in version control systems are an example of IoC. Shutdown routines on an IBM System/38 are an example of IoC.
–
Jörg W MittagJun 17 '10 at 0:23

It's a little bit subjective I think. The toolkit is the easiest. It's just a bunch of methods, classes that can be use.
The library vs the framework question I make difference by the way to use them. I read somewhere the perfect answer a long time ago. The framework calls your code, but on the other hand your code calls the library.

I think it's unanimous that a library is code already coded that you can use so as not to have to code it again. The code must be organized in a way that allows you to look up the functionality you want and use it from your own code.

Most programming languages come with standard libraries, especially some code that implements some kind of collection. This is always for the convenience that you don't have to code these things yourself. Similarly, most programming languages have construct to allow you to look up functionality from libraries, with things like dynamic linking, namespaces, etc.

So code that finds itself often needed to be re-used is great code to be put inside a library.

Toolkit

A set of tools used for a particular purpose. This is unanimous. The question is, what is considered a tool and what isn't. I'd say there's no fixed definition, it depends on the context of the thing calling itself a toolkit. Example of tools could be libraries, widgets, scripts, programs, editors, documentation, servers, debuggers, etc.

Another thing to note is the "particular purpose". This is always true, but the scope of the purpose can easily change based on who made the toolkit. So it can easily be a programmer's toolkit, or it can be a string parsing toolkit. One is so broad, it could have tool touching everything programming related, while the other is more precise.

SDKs are generally toolkits, in that they try and bundle a set of tools (often of multiple kind) into a single package.

I think the common thread is that a tool does something for you, either completely, or it helps you do it. And a toolkit is simply a set of tools which all perform or help you perform a particular set of activities.

Framework

Frameworks aren't quite as unanimously defined. It seems to be a bit of a blanket term for anything that can frame your code. Which would mean: any structure that underlies or supports your code.

This implies that you build your code against a framework, whereas you build a library against your code.

But, it seems that sometimes the word framework is used in the same sense as toolkit or even library. The .Net Framework is mostly a toolkit, because it's composed of the FCL which is a library, and the CLR, which is a virtual machine. So you would consider it a toolkit to C# development on Windows. Mono being a toolkit for C# development on Linux. Yet they called it a framework. It makes sense to think of it this way too, since it kinds of frame your code, but a frame should more support and hold things together, then do any kind of work, so my opinion is this is not the way you should use the word.

And I think the industry is trying to move into having framework mean an already written program with missing pieces that you must provide or customize. Which I think is a good thing, since toolkit and library are great precise terms for other usages of "framework".

a simple example. Let's say you implement the ISerializable interface (.Net) in one of your classes. You make use of the framework qualities of .Net then, rather than it's library qualities. You fill in the "white spots" (as mittag said) and you have the skeleton completed. You must know in advance how the framework is going to "react" with your code. Actually .net IS a framework, and here is where i disagree with the view of Mittag.

The full, complete answer to your question is given very lucidly in Chapter 19 (the whole chapter devoted to just this theme) of this book, which is a very good book by the way (not at all "just for Smalltalk").

Hum, that's an interesting viewpoint. I think the .Net Framework is actually a toolkit, composed of libraries, frameworks and a virtual machine. Most frameworks include libraries too, and often also include other tools, so in that sense, they become toolkits around the framework itself, all bundled together. So I guess you could say it's fair for .Net to be a framework.
–
didibusDec 10 '14 at 1:48

Do the "framework" qualities of .Net really outnumber it's qualities as a library and a set of tools? I doubt it, so I feel that's why the debate rages on. It's not more framework then library and virtual machine, so I feel it would be better defined a toolkit. Or even a platform I guess. Since toolkit is now often biased towards UI stuff.
–
didibusDec 10 '14 at 2:03