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.

Resource	Year	Language	Type	Description
Express	2010	Javascript	Light Framework	Minimalist back-end framework for web and mobile applications
React	2013	Javascript	Library	Component-based front-end library supported by Facebook
Angular	2016	Javascript	Light Framework	Component-based front-end framework supported by Google
Gatsby	2017	Javascript	Light Framework	React-based static site generator
jQuery	2006	Javascript	Library	Feature-rich library to facilitate DOM traversal
Sails	2012	Javascript	Heavy Framework	Fullstack application development following the MVC model (built on top of Express)
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

That’s a good list of the main frameworks for the Javascript (Node.js) and Ruby ecosystems. Note that I didn’t include many libraries, but that’s because there are thousands. I included React because it is commonly misunderstood as a framework, and jQuery because of its importance to the subsequent development of Javascript-based paradigms, even though this success has also caused its own demise.

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.
• NodeJS is neither a framework nor a library. It’s a server-side runtime environment for Javascript (i.e. running JS outside of the browser). Node is what allows and powers the JS-based back-end frameworks above.

Quiz time: could you mix Sinatra and Angular? Why/Why not? Leave a comment below.