This article originally appeared at https://vahid.blog.
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 "M EA N" 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 "M ER N" 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.
Top comments (0)