Framework vs. Library

Here’s to the age-old debate that seems to arise with every new generation of developer that breaks into the industry. While there are many articles out there on this very topic, I thought I’d take my own spin on it with some analogies that hopefully help you wrap your head around the concepts. It’s probably worth mentioning now that I’m no expert coder, developer, programmer, whatever you want to call that shared skillset many of you reading this article have. I’m just a normal guy who loves logical reasoning and prefers to use code to express this passion. Without further ado let’s dive in…

Subscribe To Our Newsletter

Get updates and learn from the best

First, it’s important that we understand the definitions of these two cornerstones of modern-day web development. Simply put, a library is code that is added to achieve a specific task or provide specific functionality, while a framework is a structure that acts as a skeleton for a project. Both come with documentation as each have their own usages and configurations. Before we get into the two major differences, one analogy to warm you up with is to think of a library as a hammer while the framework is the entire workshop. What does that even mean? Let’s start with the first, and simpler, difference: a framework has libraries, but a library does not have a framework.

Let’s look at Rails as our example of a framework, a fairly simple framework to understand. For those of you reading this that have no idea what Rails is, it’s a framework built for Ruby, specifically for web development. In Ruby you have these wonderful things called gems, which can be anything from a simple module to a full-blown framework (Rails is a gem, whoa!). In the scope of a Rails project, gems added to the project (outside of the core set that are dependencies of Rails) are more often than not, packages or libraries. Take the much beloved gem Devise, for example – we add devise into our project much like many other libraries, and after the installation (and migrations) we can leverage all it has to offer within our Rails framework!

The analogy that makes the most sense to me is that all squares are rectangles, but not all rectangles are squares. Bet you haven’t heard that since third grade! The framework here would be the square and the library is the rectangle. Frameworks have all the same characteristics of a library, but (wait, there’s) more! I do want to mention that there are many developers out there that argue that React is a framework based on the misconception that you add libraries to the project similar to Rails, Express or .NET. While the premise is actually true, the implementation is completely different, and I’m hoping that this next point drives it home.

The MAIN difference between frameworks and libraries is a concept called inversion of control. This concept simply brings into question what is in control: the framework/library or the code? Code calls upon a library, but a framework calls upon the code. Let’s circle back to that misconception of React being a framework. In every component you’ve ever created, what’s (most likely) the first line that is always at the top of your file?

import React from ‘react’;

Just by having to type that single line provides definitive proof that React is a library by definition and not a framework. If there’s still doubt, we can take a look back to Rails and we notice that nowhere within our Models, Views, or Controllers do we have to require Rails. This is because a library has to be explicitly added into wherever you need to use it, while a framework provides predetermined spots for your code to “drop in”. Don’t want to take my word for it? Take quick peek at React’s landing page. They define themselves as a library.

The analogy here is that a framework is the skeleton, a library is the clothing, leaving your code as the remaining soft tissue, organs, etc. With frameworks, your code has a designated spot where it’s supposed to go – if you were to put all your toes on your hands and fingers on your feet, I guarantee you’re going to run into some problems. That’s the same thing when working with misplacing code in a framework. A library, on the other hand, is dependent on you, the developer, calling it appropriately and using it properly. If you’re working for code for the “head” you’d probably want to add a hat and not a shoe.

Well, that’s everything I wanted to write about. First off, thanks for making it this far (assuming you didn’t cheat and skip to this part)! To summarize, the two major differences between frameworks and libraries is that frameworks have libraries, but libraries cannot have frameworks and the inversion of control. I really hope those analogies helped in the understanding of these differences. If you’re still confused feel free to say so down in the comments and we’ll try to help out however we can. If you enjoyed this article or found it informative, please drop a like and/or share the article with your friends or colleagues! We are aiming for one new blog article per week.