With all the enthusiasm surrounding React, Symfony, Vue JS and the rest, we often hear about frameworks and libraries. Whether in the front end or the back end, you will come across these terms for almost every language. So what do these labels really refer to? What is the difference between a framework and a library? Here is a definition of these sometimes misunderstood terms that everyone can follow.
A library: a toolbox to help you develop
When the English term library is used — at least to talk about a development tool — it refers to a collection of classes or functions to use in your code. What we are talking about is an inventory of tools intended to save you time in your integration and development work. It is definitely not a physical place! In French, be careful not to confuse library with the word “librairie”, which means something else entirely (a bookshop). As you will have gathered, if you use a library it is so as not to reinvent the wheel. If a resource meets your needs, works and is available, why not use it? There is in fact a reason for asking that question, but we will come back to it later, in the section “Do you absolutely have to use a library or a framework?”
Let’s get back to the definition of a library and take a concrete example to illustrate the idea. On a building site you are perfectly free to make your own hammer! You will simply have to begin your development project by setting aside time to build your tool. Although there is a lot to be said for the home-made approach, it should not be forgotten that this task can take a great deal of time. And the effort you spend developing your own tools may not go down well with your client, who — incidentally — pays you according to the time you spend on a project. So why not use a toolbox straight away? With a toolbox, all you have to do is pick up your hammer and then concentrate on your work! You are therefore more efficient and you save time. It is a very simplistic comparison, but it perfectly captures what a library is for.
Framework: a ready-made software infrastructure for coding faster
A framework is not a library! If the two terms are fairly easy to confuse, it is quite simply because in most cases a framework includes one or more libraries. Take the case of React, for example, which calls on third-party libraries for particular features such as routing.
The software infrastructure and its components
Let us explain: when we talk about a framework, what we are really referring to is a software infrastructure, also known as an application framework. That infrastructure is neither more nor less than an operating model. It might, for example, be a well-known and commonly adopted model such as MVC (Model-View-Controller) or MVVM (Model-View-ViewModel), but it could equally be some other, more exotic way of working. The software infrastructure is an integral part of a framework’s core — it is, in a sense, what characterises it! Knowing whether a framework uses data binding or some other way of manipulating code means understanding its software infrastructure. To be a little more precise, this infrastructure is itself made up of several autonomous elements called software components.
The formalism and rules imposed by a framework
If a library can be compared to a toolbox, a framework can be seen as a laboratory! In a laboratory you find raw materials, tools and, above all, safety rules to be followed. In the case of a framework, the raw materials are the variables and other parameters that give meaning to the use of the tools. The tools are the functions and classes built into the framework. As for the safety rules, they are the formalism the framework imposes. Yes — because although frameworks can have many advantages, the first being the time they save, they nonetheless dictate a strict and sometimes very rigid way of doing things. This is what we call a paradigm!
Understanding a framework’s scope and specifics
There are frameworks of every kind! Each has a different purpose: some specialise in one particular thing, others in something else. So why not have an all-in-one framework? Because a framework’s excessive size can have consequences for its weight! As you will have understood, it is above all a working document to be imported, and the most complete ones can sometimes be very heavy — like Angular, which weighs around 150 kB. In front-end development, the heavier a framework is, the longer it takes to load, and page loading suffers as a result: that is the idea to take away. This is why you will find some frameworks that try to stand out by shipping only what is strictly necessary to cover a targeted set of needs. That is the case, for example, with the JavaScript framework Mithril, which weighs only 8 kB and specialises in creating SPAs (Single Page Applications).
Incidentally, if you are looking for a JavaScript framework and do not know which one to choose, we recommend reading our article: JavaScript, which are the best frameworks for your website?
Complexity and the learning curve
Another point to raise: complexity! The more features a framework has and the more possibilities it offers you, the harder it will be to handle. Are you sure you are using 100% of its services? That is not necessarily the case, and so in order to pinpoint exactly the tools that will be useful to you, you will have to shake every branch, one by one, before things become a little clearer in this jungle. Rest assured, we are not saying a framework is an adaptation of Jumanji. That said, the substantial ones such as Angular do require sharp insight if you are to find your way around, and are therefore not necessarily the most accessible when you are a junior developer.
The advantages of a framework
- an undeniable saving of time
- a guided way of working, at least when the documentation is well written
- working with a popular and commonly adopted model
- being able to rely on a community
- dedicated tutorials and forums to help you
The disadvantages of a framework
- an imposed formalism, and often little freedom
- very rarely meets 100% of your needs
- brings with it a more or less steep learning curve
So what is the difference between a framework and a library?
Ah, here comes the long-awaited question! To answer it, you need to understand exactly who uses what. When you use a framework, it is the framework that calls your code. Let’s remember that it constitutes an application framework that wraps around your code. To come back to the MVC model, it is the framework that manipulates your code by splitting it into different layers: the view (what is displayed), the model (your data and business logic) and the controller (which connects the model and the view). You, as a developer, are simply a user of that model. So you just manage the data you inject into it, how it is processed and how it is displayed. The framework takes care of the rest, and you do not have to know how that happens. You are its user, not its administrator. By contrast, when you use a library it is your code that uses the library. Because, as we said, a library is only an inventory of available resources — and you call on those resources from your code.
Open source and free of charge: do your research before using them!
If most of the libraries and frameworks you can find on the web are free and open, it is precisely because their purpose is to make the fruit of many hours of development available to everyone. Anyone can therefore use them freely and contribute to their development by adding their own functions or classes that they feel are missing. Be careful, though: we are talking here about open-source, free libraries and frameworks such as React. That is not necessarily the case for all of them — for example the JavaScript library Kendo UI is a paid product. You can of course reuse and modify the components it contains, but you are not allowed to publish or redistribute it. If you want to use a library, it is very important to pay attention to this distinction and to look into the library’s or framework’s licence, as it could save you serious legal trouble.
Do you absolutely have to use a framework or a library?
Well, no — you are not obliged to use a framework or a library! You can perfectly well work with your own tools, and that has advantages too, including:
- being independent and free in the way you work
- having a bespoke tool, perfectly suited to your needs, without having to clear the ground first
- not getting tangled up by writing code that conflicts with the rest (hello there, Bootstrap)
- knowing your tool better than anyone
But in the end, it is as though you were creating your own in-house framework… except that yours will not be used by anyone else (unless you publish it and make it open source), and it will therefore be an obstacle to teamwork. So when should you decide to use a framework? It all depends on the circumstances: if the library meets 100% of your needs, great! If not, then you can ask yourself whether to start from scratch. It would be a shame to spend too much time “reshaping” a tool that is not suited to your needs. It is like trying to drive in a nail with a colander: you can get there, but you will have to line up an awful lot of variables.
