Rohit Singh Rana

Posted on May 21, 2021

What is the difference between Library vs Framework?

#beginners #javascript #webdev #html

While the terms Library and Framework may sound similar, they both work differently.

Many people use these two words interchangeably without knowing the profound meaning behind them.

Before we dig into the key differences between Library and Framework, let's look at the common purpose that they both serve.

Both Library and Framework are code written by some developer to solve a complicated problem efficiently.

They both give you an excellent approach to write DRY (don't repeat yourself) code.

Their purpose was to increase the reusability of the code so that you can use the same piece of code or functions again in your various project.

What is Library?

A Library is a set of code that was previously written by a developer that you can call when you are building your project.

In Library, you import or call specific methods that you need for your project.

In simple words, a bunch of code packed together that can be used repeatedly is known as Library.

Reusability is one of the main reasons to use libraries.

Let's understand this more clearly with the help of an example.

Think of you as a carpenter who needs to build a table.

Now, you can build a table without the help of tools, but it's time-consuming and a long process.

Whereas, if you choose the correct tools, you'll be able to build a table more quickly and that too without any hardship.

Think of here tools as a library. You can write your program without them.

But it will be a long process, and chances are your program will get buggy, while if you use Library, it'll be much easier for you to work with the program.

For example, if you use the in-built JavaScript fetch () method to fetch the data from API and you feel that it's not the ideal solution.

Then you can use Axios Library for the same purpose to make your work easier.

axios.post('/login', {
  firstName: 'Monica',
  lastName: 'robinson '
})
.then((response) => {
  console.log(response);
}, (error) => {
  console.log(error);
});

Some common examples of Library are:

React

React is a JavaScript library for building user interfaces.

Redux

Redux is an open-source JavaScript library for managing application state.
It's most commonly used with React

Three.js

It's another super cool JavaScript library used to create and display 3d computer graphics.

Lodash

Lodash is a JavaScript library that provides utility functions for common programming tasks.

It's more of a productivity kit in node.js

jQuery

jQuery is a JavaScript library that does the things like event handling and HTML document manipulation.

What is Framework?

A framework is a supporting structure that gives shape to your code.

In the Framework, you have to fill the structure accordingly with your code.

There is a specific structure for a particular framework that you have to follow, and it's generally more restrictive than Library.

One thing to remember here is that frameworks sometimes get quite large, so they may also use the Library.

But the Framework doesn't necessarily have to use Library.

Let's get back to our carpenter and table example for a better understanding of the Framework.

Here, if you want to build a table, then you need a model or skeleton for how the table looks, like the table has four legs and a top slab.

Now, this is the core structure of the table and you have to work accordingly to build the table.

Similar to this, Framework also provides the structure, and you have to write the code accordingly.

Let's take the example of Express and understand the restrictive nature of the Framework.

var express = require('express')
var app = express()


app.get('/', function (req, res) {
  res.send('welcome to dev.to!! ')
})
app.post('/', function (req, res) {
  res.send('POST request to the dev.to homepage')
})

Here express is designed in such a way that it is going to look only for specific methods (get/post) and specific parameters.

You can't name the methods whatever you want to, and you have to name the methods as per the documentation.

Some common examples of Framework are:

Angular

Angular is a JavaScript framework for web and mobile development.

Django

Django is a fully featured server-side web framework written in
Python.

Express

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

Rails

Rails is a web application development framework written in the Ruby programming language.

Spring

Spring Framework is an open-source framework for building web applications with Java as a programming language.

Key Difference between Library vs Framework

The main key difference between the Library and Framework is something known as inversion of control.

Let's understand this inversion of control more in detail.

When you import a library, you have to call the specific methods or functions of your choice so, and it's up to you when and where to call the Library.

Here, you are in charge of flow.

On the other hand, Framework itself makes a call to your code and provide you with some space to write down details.

So, while using framework your framework is in charge of flow.

In Library, your code is going to call the Library whereas, in Framework, your code is being called by Framework.

Conclusion

I know it's getting too confusing but stay with me. I'll end this with one last crucial point.

Here is a simple thing to remember Framework is often more restrictive and generally have a more set of rules.

Whereas, Library is not bounded by many rules.

I hope you get a broader perspective of what's the difference between Library and Framework.

If you find my work interesting and worth reading you can appreciate me on Twitter and LinkedIn.

All kinds of Feedback are welcomed in comments.

Top comments (31)

peerreynders • May 21 '21 • Edited

Some common examples of Library are: React

yet later:

In the Framework, you have to fill the structure accordingly with your code.

Creating a React component is filling that structure (even as a function component).

The main key difference between the Library and Framework is something known as inversion of control.

Correct.
Your React components are managed/invoked by React. By calling ReactDOM.render() you hand over the UI/main thread to React. Past that point the components may use the tooling provided by React - but the components only get control when React decides to give them control.

For more details React is a (view component) framework.

One could argue that by calling itself a library React has greatly contributed to the library vs framework confusion.

Jack • May 21 '21

This. I've never understood the insistence that react is not a framework as it totally is. Maybe it was originally a library, but the fact that we now build "react apps" is an obvious sign that it's a framework.

To me a framework is something that drives and control a major part of your code, whereas a library just helps you in writing your code.

For the same reasons I always feel like express is more library than framework. Essentially its just a thin wrapper around the http module, and aside from setting up routes, it has no control or interest in how the rest of your app works

peerreynders • May 21 '21 • Edited

For the same reasons I always feel like express is more library than framework.

1988 Johnson & Foote:

The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.

Looking at the express Hello World:

express() returns a generic express server.
app.get() "tailors" that generic server with user code - which will only be invoked by the express server.
app.listen() starts that generic server with the user code that "tailors" its operation ...

The framework often plays the role of the main program in coordinating and sequencing application activity

... which is exactly what app.listen() accomplishes. So express ticks all the boxes for a framework - while the main thread configures the generic server, once running, the generic server calls all the user code that was supplied via configuration.

It really comes down to:

If your code calls it, it's a library.
If it calls your code, it's a framework.

Off course by that definition the http module itself is a "framework" ...
node.js Hello world
... because the module "plays the role of the main program" and the module "calls the user code".

This just illustrates that a "framework" doesn't have to be big, complex or "all batteries included".

Jonathan Mwebaze • May 25 '21

"Something that drives and controls a major part of your code", don't you think this makes create-react-app the framework and reactjs just a library, just like react-scripts, react-dom, redux etc... We don't build react apps, we use react to build applications. React is just part of it, just like react-dom or even react-router-dom

peerreynders • May 25 '21

TL;DR: "Framework" !== "Application Framework"

See my other comment.

React is the core that is responsible for "the operation in the manner of a framework" - orchestrating the application activities and only delegating to user code via inversion of control.

React components (user code) aren't being run by the event loop but by React.

So while React may look like it's just a layer between the components and the JavaScript runtime it's actually React running (calling) the components - components don't use React unless React calls them first.

Luke Shiru • May 22 '21 • Edited

React is a library still, because the idea with it (and any other library that uses VDOM or some other reactive engine), is that it takes care of the DOM mutations for you, so you can design your components and focus in the actual logic instead of dealing with the DOM yourself.

You define how to handle routing, testing, styling, state, component style and so on.

From your point of view, React would have to give you control over the VDOM trough functions that you'll call to "be a library", which is kinda ludicrous. At that point you should just implement the VDOM yourself.

On the other hand you have actual frameworks like Angular, in which you have to use classes, with their decorators, their template system, their cli tools, their testing engine, their services, their routing, and so on (and yet the way the components work in there still sucks 😅).

In short: React is an abstraction layer of the DOM, that includes some optional useful tools to handle state (that you can use if you want). But that's it. Everything else is up to you. You can even opt out of JSX if you want to. Angular takes all those decisions and more for you.

peerreynders • May 22 '21 • Edited

From your point of view, React would have to give you control over the VDOM trough functions that you'll call to "be a library", which is kinda ludicrous.

I fail to see how that is in any way ludricrous. Call it a VDOM framework then.

What exactly does the JSX <p>{count}</p> do? It desugars to:

React.createElement('p', null, count);

So a React (functional) component's return value is a ReactElement.

2005 Martin Fowler: InversionOfControl

A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

So while functional components have eliminated the need to subclass React.Component, functional components are "plugged into" React because that is how React creates the component tree and each and every functional component returns a ReactElement - a type that is specific to React and created by React via React.createElement. And the relevant location for that ReactElement is determined by the location of the component instance within the component tree.

A simple working example:

<!doctype html>
<html lang="eng">
  <head>
    <meta charset="utf-8"/>
    <title>React is a Framework</title>
  </head>
  <body>
    <main class="js-root"></main>
    <script src="https://unpkg.com/react@latest/umd/react.production.min.js"></script>
    <script src="https://unpkg.com/react-dom@latest/umd/react-dom.production.min.js"></script>
    <script>
     (function () {
       // https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L276-L279
       //
       // function createElement<P extends {}>(
       //   type: FunctionComponent<P>,
       //   props?: Attributes & P | null,
       //   ...children: ReactNode[]
       // ): FunctionComponentElement<P>;
       //
       //
       // https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/react/index.d.ts#L158-L160
       //
       // interface FunctionComponentElement<P> extends ReactElement<P, FunctionComponent<P>> {
       //   ref?: 'ref' extends keyof P ? P extends { ref?: infer R } ? R : never : never;
       // }
       //
       const render = ReactDOM.render;
       const h = React.createElement;
       const useState = React.useState;
       const useEffect = React.useEffect;

       // --- BEGIN user supplied component oriented application
       function App(_props) {
         const count = useCount(0);
         return h('p', null, count);
       }

       const MS_PER_COUNT = 1000;
       const START = document.timeline.currentTime;
       const increment = (value) => value + 1;

       function useCount() {
         const [_dirty, setDirty] = useState(0);
         // Base `count` on a fresh timestamp
         const count = Math.floor((performance.now() - START) / MS_PER_COUNT);

         useEffect(() => {
           const refresh = () => setDirty(increment);
           // Base `delay` on a fresh timestamp
           const delay = (count + 1) * MS_PER_COUNT - (performance.now() - START);
           const timeoutID = setTimeout(refresh, delay);
           return () => clearTimeout(timeoutID);
         });

         return count;
       }

       // --- END application
       // "React is your Application": handing over application to React
       render(h(App), document.querySelector('.js-root'));
     })();
    </script>
  </body>
</html>

That last render statement is where the "inversion of control" kicks in. render is the framework function that "plays the role of the main program".

Contrast that to µhtml which is a library:

<!doctype html>
<html lang="eng">
  <head>
    <meta charset="utf-8"/>
    <title>µhtml is a Library</title>
  </head>
  <body>
    <main class="js-root"></main>
    <script type="module">
     import { render, html } from 'https://unpkg.com/uhtml?module';

     const MS_PER_COUNT = 1000;
     const START = document.timeline.currentTime;
     const root = document.querySelector('.js-root');

     function update(timestamp) {
       const elapsed = timestamp - START;
       const count = Math.floor(elapsed / MS_PER_COUNT);
       render(root, html`<p>${count}</p>`);
       const refresh = () => requestAnimationFrame(update);
       const delay = (count + 1) * MS_PER_COUNT - elapsed;
       setTimeout(refresh, delay);
     }

     update(START);
    </script>
  </body>
</html>

html is a tagged template which returns an object that is designed to produce something that extends HTMLElement a platform type (not a framework type). render is a convenience function that attaches that DOM element instance to the indicated platform location.
In terms of the script the final statement invokes a user function (not a framework function) - so the user code is always running the show - so there is no framework in control here.

Interestingly µhtml is the foundation for µland - a React-style framework:

<!doctype html>
<html lang="eng">
  <head>
    <meta charset="utf-8"/>
    <title>µland is a Framework</title>
  </head>
  <body>
    <main class="js-root"></main>
    <script type="module">
     import {
       Component,
       render,
       html,
       useState,
       useEffect,
     } from 'https://unpkg.com/uland?module';

     // --- BEGIN user supplied component oriented application
     const App = Component((initialState) => {
       const count = useCount(initialState);
       return html`<p>${count}</p>`;
     });

     const MS_PER_COUNT = 1000;
     const START = document.timeline.currentTime;
     const increment = (value) => value + 1;

     function useCount() {
       const [_dirty, setDirty] = useState(0);
       // Base count on a fresh timestamp
       const count = Math.floor((performance.now() - START) / MS_PER_COUNT);

       useEffect(() => {
         const refresh = () => setDirty(increment);
         const delay = (count + 1) * MS_PER_COUNT - (performance.now() - START);
         const timeoutID = setTimeout(refresh, delay);
         return () => clearTimeout(timeoutID);
       });

       return count;
     }

     // --- END application
     // Handing over application to µland
     render(document.querySelector('.js-root'), App(0));
    </script>
  </body>
</html>

note how the user code is wrapped in a framework specific function type (via Component)
the final statement uses render, a framework function, exercising "inversion of control".

you have actual frameworks like Angular.

Why is it that people associate "framework" with size and complexity? The criteria for categorizing software as a "framework" were established long before either Angular or React were created. While the statement "React isn't an application framework like Angular" may be correct that in no way implies that React isn't a framework in its own right.

Why is it that people act as if the sky is going to fall on their head if they were to utter "React is a framework"?

Luke Shiru • May 22 '21

You mentioned it in your example, when you write:

const Anchor = props => <a rel="noopener noreferrer" {...props} />

Turns into:

const Anchor = props => _jsx("a", { rel: "noopener noreferrer", ...props });

So basically, every time you write JSX, you're calling a function, just with a more expressive syntax. You can then call yet another function to render that into the place of the DOM you desire:

render(<Anchor />, document.querySelector("some-element-in-the-dom"));

If you don't call that function, or you desire to transform the output of the Anchor before doing so, or you prefer to render it as plain text instead of using the DOM, or whatever else, then you just do so. As I mentioned before, React is just abstracting the complexity of the DOM, and that's it.

Contrast that with doing it by hand:

const createElement = (tagName, props) => Object.assign(document.createElement(tagName), props);
const render => (element, target) => target.appendChild(element);

const Anchor = (props = {}) => createElement("a", { rel: "noopener noreferrer", ...props });

render(Anchor(), document.querySelector("some-element-in-the-dom"));

The main difference is that with that "vanilla approach" I now need to take care of every update in the DOM by hand, while React's render does that for me. Yes, it is calling my functions by itself, but is because it basically took a really outdated API (the DOM) and wrapped it with the VDOM enabling a functional approach to the DOM (one-way data flow), instead of those disastrous double bindings of the past.

I used both µhtml and µland in the past (I generally try out everything made by WebReflection because he is a fantastic developer), but your example with µhtml you're just calling render in a fixed interval, but that render expects the output of html, which yes is a HTMLElement, but how is that different from using a plain object with a convention (besides the fact that HTMLElement is way more complex than needed)? React is just making that "interval" for you. Does that turn it into a framework from your PoV? Would you take React as a library if it let you call render by intervals controlled by you?

PS: If you like the tagged template approach, there is a great library by developit (the creator of preact) that gives you that, but you define what to call when the function is used: github.com/developit/htm

peerreynders • May 23 '21 • Edited

I generally try out everything made by WebReflection because he is a fantastic developer

And he never tires of pointing out to everybody that React is a costly abstraction (1, 2, 3, 4, 5, 6, 7, 8).

but your example with µhtml you're just calling render in a fixed interval, but that render expects the output of html,

Which is exactly what one does when rendering with a library.

React is just making that "interval" for you. Does that turn it into a framework from your PoV?

The point is that a functional component is nothing but a glorified (but "tailored") render() function.

But the difference is that in the case of µhtml the user code is always in control - html and render are simply helper functions for generating and placing the DOM nodes so that the user code doesn't have to deal with them directly making the user code more declarative than manipulating the DOM manually.

In React the user code doesn't call function components ("tailored render functions"); the function components are user code which are handed over to React which then invokes them as it deems fit - that is what makes React a framework.

That said I have yet to run across a VDOM library - all VDOM abstractions I have encountered are operating in the manner of a framework.

there is a great library by developit

I'm familiar with Jason Miller's work.

Luke Shiru • May 23 '21 • Edited

I don't get how html and render from µhtml are "just helper functions" but _jsx and render from React aren't that as well from your PoV. I mean your µhtml components are also handed over to µhtml's render. The way I see it:

React's _jsx takes some parameters and returns an object.
µhtml's html takes a template string and returns an HTMLElement.
Both React's and µhtml render then take some parameters and deal with the complexity of the DOM for you.

What's the concrete thing that from your Point of view makes React a framework and µhtml a library? I mean I would get it if you considered both a library or both a framework, but you actually see them as two different things.

PS: I noticed that you edited your comment and added links to Andrea's tweets and examples, but in one of those tweets you can see that he says:

My libs variety is all about providing any sort of pattern, so pick your pattern, then chose.

They don't stop being libs just because they have other patterns.

Also, just in case, I'm not advocating in favor of React because of performance/size, because there are libraries out there way better than React (like Preact). I'm just saying that it makes sense to call it a library.

peerreynders • May 23 '21 • Edited

What's the concrete thing that from your Point of view makes React a framework and µhtml a library?

µhtml: What calls the update() function ? update(START) - i.e. user code. By extension html and render are only called by user code.
React: What calls the App() component? React. render(h(App), document.querySelector('.js-root')); only hands over the component to React - it's up to React to invoke it. By extension any code inside of App() (the "user code") only runs when React wants it to.

As I wrote in my second comment:

If your code calls it, it's a library.
If it calls your code, it's a framework.

Luke Shiru • May 23 '21 • Edited

Isn't µhtml calling my component as well? Isn't the developer the one calling React's render?

Both render functions need to be called by the user and take something from the user and either use it, or call it when they need to do it. The difference is that React's render doesn't make you do the update, while µhtml does.

So it something like:

const uHTMLRender = something => something();
// vs
const reactRender = something => schedule(something);

If that's enough to consider React a framework, then ok, there are lots of libraries out there that should be called frameworks instead.

It might be worth mentioning that Frameworks and libraries have different definitions in FE vs the classic. I mean in the FE generally we consider something a Framework when it comes bundled with an answer to every question (routing, testing, components, and so on) and is extremely opinionated, while we consider a library something that doesn't do that (unopinionated and good for one thing). That's why classically we put React in the library bucket and Angular in the Framework bucket.

Still, I guess we can close it in a "we agree to disagree". I mean I think I get why you consider React a Framework, but lets say that if it actually is a framework, is an extremely simple and unopinionated one, that only takes care of your interactions with the DOM.

peerreynders • May 23 '21

Isn't µhtml calling my component as well?

The point is by the time render() returns nothing of µhtml is left of the call stack. The user code is in complete control.

The difference is that React's render doesn't make you do the update, while µhtml does.

The relevant difference is that with React your code calls render() once during the entire lifetime of the application session and React remains active for the remainder of that session - orchestrating all actions that the application takes from that point on (i.e. React is in charge).

µhtml's render() has to be called whenever your code wants to patch the DOM; so render() is called many times during the application's lifetime - and when render() returns your code is completely in the driver seat - not µhtml.

I mean in the FE generally we consider something a Framework when it comes bundled with an answer to every question (routing, testing, components, and so on).

What you are describing is an application framework. Not all frameworks are application frameworks. So if you are correct that means that in FE development application framework has been contracted to framework narrowing the meaning of the term significantly.

Still, I guess we can close it in a "we agree to disagree".

At this point your perspective seems to be:

it's a framework if it's an application framework
otherwise it's a library irrespective of the fact whether or not it operates in the manner of a framework.

My perspective is:

it's a framework if it remains active for the entire application session lifetime and orchestrates user code via inversion of control.
a library provides capabilities that abstracts certain details away but these capabilities are only temporarily and directly invoked by the user code; after the capability returns the user code is completely in charge again to orchestrate the application's actions as it deems fit.

I think at this point it's clear which view I find more obvious and less confusing.

React ... is an extremely simple and unopinionated one, that only takes care of your interactions with the DOM.

Calling React unopinionated is in my view misleading at best. It certainly is less opinionated than Angular but that isn't the same thing as being unopinionated. In fact choosing React as your abstraction has a significant impact on your client side solution architecture.

Redux maintainer Mark Erikson made an astute observation:

I've noted that React devs can often be classified into two groups: those who see the React tree as their app / have a "component-centric" view, and those who view their state / logic as their app / have an "app-centric" view.

The majority of Kent C. Dodds's article Application State Management with React explores the component-centric approach which goes beyond "taking care of interactions with the DOM" - it essentially uses React as if it was an application framework to the point that "React is your Application".

The "app-centric" approach tries to separate the application from React, narrowing React's responsibilities to just "taking care of interactions with the DOM". However as soon as you use an integration like React-Redux you are coupling your React code with the way Redux operates, trading away the opportunity to cleanly separate your UI from the client-side aspect of your application (and as David Khourshid points out Redux has its own set of trade offs).

In UI As An Afterthought Michel Weststrate discusses how he builds the client-side application around MobX rather than having the UI abstraction dictate the structure of the application (a modern take on Segregated DOM). Having a clear boundary between React (the UI) and the rest of the client-side application is important to use web workers effectively.

The point is that you have to be pretty disciplined and determined (i.e. it's not the path of least resistance) if you want React to just "take care of interactions with the DOM".

Heiker • May 22 '21

The way I see it, if you let React become the center of the universe (meaning your app/project), you got yourself a framework. I believe strongly opinionated frameworks are not the only kind of framework.

snyntakk404 • May 25 '21

React is more of a mix of both framework and library. It has the key pieces of a library but contains concepts of a framework. Thus I classify it as both with it leaning towards framework. This was a great article but it some editing with the examples.