What's the difference between a framework and a library?
What’s a framework? What’s a library? Aren’t the two terms interchangeable? Is React a framework or a library? What about NodeJS? And what’s Rails? Who cares, anyway? So many good questions, you have.
Answers, I shall offer you.
Let’s actually answer the last question first, because it’s the most important: why should you care about the difference?
Knowing the difference will help you better understand how to make sense of all the existing resources currently available for web application development, and all future resources that are sure to keep popping up.
Moreover, understanding whether each resource is a framework or a library will help you determine whether you can mix them together in the same application. For example, can you mix Angular and Express? Rails and React? Angular and React? Rails and Express?
Here’s a hint: you usually cannot or should not mix two frameworks together, but you can (and usually have to) mix a framework and a library. Indeed, you usually need to combine your framework with multiple libraries, because each library does one thing well, and an application often makes use of many libraries because it needs to do many things well.
The most significant technical difference between a framework and a library is who’s in control of the execution flow. With a library, you’re in control: you determine when to call the library, if at all. When working in a framework, however, you write code to fill in the gaps of the framework, because the framework is in control of the execution flow. The framework calls the code that you write.
As the saying goes: you call the library – but the framework calls you.
Both libraries and frameworks are installed the same way (e.g. as a package in Node.js, or a gem in Ruby). Both may also further be categorized as either advancing the front-end (client-side) or the back-end (server-side) of the application, or both (fullstack).
The last important distinction to make is that a framework can either be heavy or light, depending on how many restrictions and conventions it imposes on you. Using a heavy framework allows you to quickly ramp up and ship an application because the framework comes with significant pre-built scaffolding that you don’t have to worry about creating from scratch. The drawback of a heavy framework is more rules and conventions you have to follow.
Using a light framework means you can customize more things, and structure them however you want, but it also requires more time and more effort. Some heavy frameworks are built on top of light frameworks–i.e., they simply add more structure on top of the original scaffolding provided by the light framework.
Here are some of the most popular frameworks and libraries, including initial release year.
|Rails||2004||Ruby||Heavy Framework||Fullstack application development following the MVC model|
|Sinatra||2007||Ruby||Light Framework||Minimalist back-end framework for web and mobile applications|
A few notes:
- Usually, you wouldn’t mix two frameworks together. However, the exception in the list above is that you can mix Express and Angular (the “MEAN” stack)–but that’s because they’re both light frameworks, and they each focus on a different side of the application.
- It wouldn’t make sense to mix Angular and React, although one is a framework and the other is a library, because they both provide front-end rendering paradigms.
- You could combine Express and React, however–and many indeed do (the “MERN” stack).
- You can mix Rails and React, since one is a heavy framework for fullstack applications, and the other is a library for front-end rendering. You wouldn’t want to mix Rails and Express, however, since they both provide back-end frameworks.
- Sails is just one example of a heavy framework built on top of Express. There are many more.
Quiz time: could you mix Sinatra and Angular? Why/Why not? Leave a comment below.