If you are learning software development, you will eventually come across two words that seem like they should mean almost the same thing:
Framework. Library.
Both contain code written by other developers.
Both save us from building everything from scratch.
And both can even be used inside the same application.
Imagine having to manually write your own code every time you need to validate an email address, make an HTTP request, create application routes, connect to a database, or build a user interface.
That would be exhausting.
This is why developers rely on frameworks and libraries. They let us reuse solutions instead of rebuilding everything ourselves.
But then why is one called a framework and the other a library?
More importantly, if both contain code somebody else already wrote, what really separates them?
Let's start somewhere completely unrelated to programming.
A kitchen.
Table of Contents
- What Is a Framework?
- What Is a Library?
- Framework vs Library: The Real Difference
- Another Way to Understand the Difference
- How Frameworks and Libraries Work Together
- Framework vs Library: Which Should You Use?
- The Easiest Way to Remember the Difference
What Is a Framework?
Imagine you are a chef walking into a professional kitchen.
Before you cook anything, a lot has already been arranged for you.
There is a cooker.
There is a sink.
There are refrigerators.
There are worktops, knives, plates and other equipment.
You didn't build the kitchen.
But the kitchen doesn't cook the meal either.
You are still the chef.
The kitchen simply gives you the environment you need to do your work.
That is similar to a framework.
In our example:
- Chef = Developer
- Kitchen = Framework
- Meal = Application
The developer still builds the application, just as the chef still prepares the meal.
But the chef doesn't have to build and arrange an entirely new kitchen every time he wants to cook.
The cooker already has its place.
The sink already has its place.
The worktop already has its place.
The tools are there and ready to be used.
A framework works in a similar way.
A framework is a pre-built structure that gives developers an environment for building software.
The important word here is structure.
A framework doesn't build the application for you.
You still write the application.
But instead of deciding how absolutely everything should work from scratch, you start with an environment that already provides tools, conventions and an established way of doing certain things.
Depending on the framework, that can include things like routing, forms, application structure, authentication, data handling and other common parts of building software.
Different frameworks provide different things.
But the main idea remains:
You are building your application inside an environment the framework provides.
Angular is a good real-world example.
Angular doesn't give you just one function for one particular job. It gives you a wider environment for building web applications, with things like components, routing, forms and dependency injection working as parts of the same system.
So when you build with Angular, the framework becomes part of how the application itself is built and organized.
And this brings us back to our chef.
The kitchen gives him the environment.
It gives him the cooker, sink, worktops and tools.
But having a kitchen doesn't mean the chef suddenly has everything he needs for every part of the meal.
Sometimes he still needs something for one particular job.
And that is where our library comes in.
What Is a Library?
Let's stay with the same chef.
For part of his meal, he needs tomatoes, peppers and onions.
He could get all of them separately.
Wash them.
Cut them.
Blend them.
Boil them.
Prepare everything himself.
There is nothing wrong with that.
But imagine that for the part of the meal he is making, there is already a prepared tomato purée or sauce that does some of that work for him.
Now he doesn't have to repeat every step from the beginning.
He takes it when he needs it, adds it to his food and continues cooking.
That is very similar to what a library does.
A library is a collection of pre-written code that developers can use to perform a particular task or group of related tasks.
Someone has already done part of the work.
You bring that work into your application when you need it.
And there is something important happening here.
The seasoning does not control the kitchen.
It doesn't decide what the chef is cooking.
It doesn't decide where the plates should go.
It doesn't reorganize the kitchen.
It simply waits until the chef needs it.
The chef decides when to use it.
We can see the same thing in actual code.
A Real Library Example: Axios
Imagine your application needs to get a list of users from an API.
You could handle that request yourself, or you could use a tool that already gives you what you need for making HTTP requests.
One example is Axios.
First, you bring Axios into the file because you need it:
import axios from "axios";
Then when your application needs the users, you call it:
async function loadUsers() {
const response = await axios.get("/api/users");
console.log(response.data);
}
loadUsers();
Look at what happened.
You imported Axios for a particular job.
Then your code decided when to use it.
Your application called loadUsers(), and inside it, your code called Axios.
Behind the scenes, the relationship is basically:
Your application
↓
axios.get()
↓
Axios does its job
↓
Result returns to your application
Axios performs the task you asked it to perform.
It doesn't suddenly decide how the rest of your application should work.
It doesn't decide what pages your application should have.
It doesn't decide where all your files should go.
It doesn't become the architecture of the application.
You brought it in because you needed it for a particular job.
Just like the seasoning.
And now we can finally get to the difference that matters.
Framework vs Library: The Real Difference
Let's go back to the question we started with.
A library contains code somebody else wrote.
A framework also contains code somebody else wrote.
A library saves you time.
A framework also saves you time.
So the fact that they both contain reusable code cannot be the full difference.
The real difference becomes clearer when we look at control.
More specifically:
Who decides when certain parts of the application should run?
With Axios, we already saw the answer.
axios.get("/api/users");
Your code decides when that happens.
You are basically telling Axios:
I need you here. Do this for me.
The library performs the job and your application continues.
A framework has more control over the larger environment your code is running inside.
You give the framework parts of your code, and the framework can decide when some of those parts need to run.
That doesn't mean you stop writing functions.
It doesn't mean you stop calling functions.
And it definitely doesn't mean the framework controls every single decision in your application.
It means the framework controls more of the application's overall flow than a normal library does.
There is a technical name for this.
Inversion of Control
It is called Inversion of Control, or IoC.
The name sounds more complicated than the idea.
In this context, think of it as:
Who gets to decide when certain code runs?
With our Axios example, your code is making that decision.
import axios from "axios";
function loadUsers() {
return axios.get("/users");
}
loadUsers();
You decide when loadUsers() should run.
Inside it, you decide when Axios should run.
Now take a small framework example.
In Vue, you can give the framework code that should run after a component has mounted:
import { onMounted } from "vue";
onMounted(() => {
loadUsers();
});
You still wrote loadUsers().
You still registered the code yourself.
But you are not the one deciding when the component has finished mounting.
Vue knows when that happens.
You are basically telling the framework:
When this happens, run this for me.
The framework reaches that point in its lifecycle and runs the code you gave it.
That is the part that has been inverted.
Some of the decision-making about when your code runs now belongs to the framework.
Vue calls these points lifecycle hooks.
This is also why developers often shorten the framework-library difference to:
You call a library. A framework calls your code.
That sentence is useful, but it is a simplification.
You obviously still call plenty of functions while using a framework.
The point is that the framework owns more of the larger flow and gives your code places to fit into that flow.
Martin Fowler goes deeper into this idea in his explanation of Inversion of Control.
But we don't need to leave our kitchen to understand it.
The seasoning does nothing until the chef decides to use it.
The kitchen is different.
The chef is already working inside the space, tools and setup the kitchen provides.
That is the difference we have been building towards.
Framework vs Library at a Glance
Now the normal comparison becomes much easier to read:
| Feature | Framework | Library |
|---|---|---|
| Main role | Provides structure for building an application | Provides functionality for particular tasks |
| Control | Controls more of the application's overall flow | Your code normally decides when to call it |
| Structure | Usually comes with conventions | Usually fits into your existing structure |
| Scope | Often affects a larger part of the application | Usually focuses on a particular problem or related set of problems |
| Example | Angular | Axios |
| Our analogy | Kitchen | Seasoning |
The shortest version of the table is still:
You build within a framework. You use a library.
There is one more part of the difference worth understanding, though.
Frameworks don't only affect control.
They can also affect the way you work.
For that, let's leave the kitchen for a moment.
Another Way to Understand the Difference
Let's create a fictional character called Ben.
Ben starts a new job.
On his first day, the company gives him a work laptop.
The laptop already has its operating system, approved applications, security settings and tools required for his work.
Ben is still the person doing the job.
He can still build great things.
But he is working inside an environment created by the company.
There may be applications he is expected to use.
There may be places certain files should go.
There may be security rules he needs to follow.
There may be an established way the company expects certain tasks to be done.
That is similar to working with a framework.
The framework gives you an environment and a pattern to work with.
You are still the developer building the application, but you are not starting from a completely blank environment.
Now imagine Ben gets home and opens his personal laptop.
He needs to edit an image, so he installs Photoshop.
Photoshop doesn't suddenly decide how every other part of his laptop should work.
It doesn't decide where every folder on the laptop must go.
It is simply a tool Ben chooses to use for a particular job.
That is closer to a library.
And this also explains something that happens in real projects.
If Ben decides to replace one application on his personal laptop, the rest of his laptop can remain mostly the same.
Changing his entire work environment is a much bigger decision.
The same can happen in software.
If an application uses a library in a few places, replacing that library may mainly affect those places.
Replacing the framework the application was built around can affect much more because the application's structure and conventions may already depend on it.
If we go back to our kitchen:
Changing the seasoning is usually easier than changing the kitchen.
How Frameworks and Libraries Work Together
A real application does not normally have to pick one side and stay there.
You can build an application inside a framework and still use libraries for specific jobs inside that application.
Our kitchen already shows why this makes sense.
The chef works inside the kitchen.
That doesn't stop him from using seasoning.
The seasoning doesn't suddenly become the kitchen because it is being used inside one.
And the kitchen doesn't stop being a kitchen because the chef brought in something extra.
The same relationship exists in software.
A framework can provide the larger structure of an application while different libraries help with particular pieces of functionality inside it.
It can even go one step further.
A framework itself may use, include or depend on libraries internally.
Angular's own documentation, for example, describes Angular as a web framework while also describing the broader collection of tools, APIs and libraries it provides.
So the fact that something contains reusable code does not automatically tell us whether it is a framework or a library.
That takes us back to the more useful question:
What role is this thing playing?
Is it something your application brings in for a particular job?
Or is your application being built around the structure and flow it provides?
Once you look at it that way, the distinction becomes much easier.
Framework vs Library: Which Should You Use?
By now, the choice is probably less dramatic than it sounded at the beginning.
A framework and a library are solving problems at different levels.
Sometimes you already have the structure of your application and simply need something to handle one particular job.
A library may be all you need.
Other times, you want a wider environment that gives your application structure and an established way to build different parts of it.
That is where a framework can make sense.
And a lot of the time, you will use both.
The framework gives you the environment.
The libraries help you solve particular problems inside that environment.
So there isn't really a winner between the two.
What matters is what you are trying to build and what kind of help you need while building it.
The Easiest Way to Remember the Difference
If you forget everything else in this article, remember the kitchen.
The framework is the kitchen.
It gives you the environment and structure in which you build.
The library is the seasoning.
You bring it in when you need it for a particular job.
The developer is the chef.
You are still the person doing the actual work.
And the application is the meal.
That is what you were trying to create in the first place.
If you want the technical version after all of that:
Your code normally calls a library. A framework controls more of the application's flow and calls into the code you provide.
So the next time you see the words framework and library, don't worry about memorizing two definitions and hoping you remember which is which.
Go back to the kitchen.
Ask yourself what role the tool is playing.
Is it something you are bringing in to perform a job?
Or are you building your application inside the structure it provides?
If you can see that difference, the names become much easier to understand.
Top comments (0)