What's the difference between a library and a framework?

Having a look at this comment by @kayis from another thread, I'm wondering if you agree with this statement?

K • Sep 27 '18

People have different definitions for library and framework

One definition I know is:

• a framework is a software where you plug your code into
• a library is a software that you plug into your code

In terms of this definition, React is a framework.

But some people, especially in the front-end world, say a framework has to bring stuff like routers and/or widgets etc. pp.

So Angular, Ember.js and ExtJS are frameworks, but React isn't, because it only gives you the means to build components and render them into the DOM.

Yes? No? Why?

Comments

[rhymes]

I agree.

One of the first frameworks I encountered was Twisted Matrix (single threaded async network library for Python) and one of the reasons why its learning curve was deemed steep at the time was because the entire app had to be designed around it: non blocking calls, use of deferreds (similar to promises), event driven, callbacks and so on.

So, as K said, you had no choice but to plug and adapt your code to it. The more you tried to use it as a library the less the chances to make it work.

The simplest example from the homepage:

from twisted.internet import protocol, reactor, endpoints

class Echo(protocol.Protocol):
    def dataReceived(self, data):
        self.transport.write(data)

class EchoFactory(protocol.Factory):
    def buildProtocol(self, addr):
        return Echo()

endpoints.serverFromString(reactor, "tcp:1234").listen(EchoFactory())
reactor.run()

the only "non framework", business logic, code is what to do with the data received on the TCP connection, in this case it's echoed back with this line self.transport.write(data).

This to me is a clear example of a framework.

Maybe in other cases the line is less defined.

[Adrian B.G.]

Not really, for multiple reasons.

A framework is usually a collection of libraries that work together to serve a greater purpose.

Also if you "plug your code into" anything, a framework or database you:

• are making a reverse dependency (now your code cannot exists without the 3rd party dependency)
• downgraded the business logic from being the core of your software as it should be, and now the framework is. From this derives other negatives outcomes as well: harder to test, harder to pivot, harder to change the framework/database, spaghetti between the implementation and business.

These are all good reasons for not using opinionated frameworks or put your code in classes that extends a framework class. If you cannot transform your Web API to a CLI api probably you are more "vendor-lock-in" then you have realized.

The framework should be an implementation detail, on the outer layers of your app, like all presenters, databases, repositories and so on. They are all tools, servants of your business (actual problem you try to solve) code.

[Martin Kiesel]

Yes.

[Sethu Senthil]

Yeah, A Framework is "something" that calls your code while a library is something you call in your code. But React is an interesting one, I have a hard time believing it as a library since it inherits many properties of a framework such as Angular.

[Jonathan Irvin]

I've often read that React isn't a framework, it's a library. While you can use React by itself, it's best suited with an array of other libraries. Then it becomes a framework.

Angular is a framework. It has a suite of applications that all have a purpose. Angular can't work alone.

I'd look at it this way:

• a library is a single tool in a toolbox.
• a framework is a toolbox itself.

[Jan van Brügge]

I agree, a framework dictates the architecture of your code, a library does not.
I think React is a great example, because does force a component model (and more) on you. But in contrast to other frameworks that give you a complete "batteries included" solution, React only does DOM (one of the reasons why I dont like it).
A library is something like snabbdom. It makes no assumtion on how your app is structured, it just gives you a patch function to apply a virtual dom description to the real dom. You can then build your architecture how you want.

[Marcus M]

React has a special place in this discussion.

I would like to add a comparison for to your statement "the framework dictates the architecture of your code", for the easier understanding the difference between them:

• The framework is the foundation of your house.
• The library is the garage that you have your tools in.

By that principle I think React can be both but it heavily depends on how you use it.

[deleteme deleteme]

A framework does a lot of things well.

A library does one thing well.

---

Rails is a framework.
Phoenix is a framework.
OTP is a framework.

React is a library.
Momentjs is a library.
HTTPoison is a library.

[Nested Software]

I agree with that way of putting it. To me a framework dictates how we develop our applications, whereas a library is an api that we can call. It's much easier to replace a library than a framework.

Some people want to call React a library because it doesn't include some tools out of the box the way that other technologies like Angular or Vue do. I'd say the scope of what a framework offers isn't so important. At the end of the day, when we are building a React app, we're very much plugging our code into React's abstraction over what a browser looks like. That's enough for me to consider it to be a framework.

All this being said, what matters most is for people to understand one another. If you and I are both clear about what some technology does and does not do, that's all that matters. We may disagree about what to call it, but as long as the basic understanding around it is shared, then I don't really see a problem.

[Jordan]

Library is build on top of framework which make developer life easier

[Thomas Leathers]

Agreed. A framework requires code to be structured around it. A good example would be my pygame virtual window manager framework, strazoloid, which i touched on in my post on my gopherspace client.

In example, strazoloid's window class function-based callbacks are time-sensitive, as all rendering and event processing for the windows, desktop class, and window manager, happens in one thread. This means the programmer needs to run lengthy operations in separate threads, and limits the program's structure.

as far as libraries, pygame itself is more a library than a framework, as its API can be used in just about any structure of program in python.

as per writing/using a library vs a framework, it really depends on the task. using a framework just for drawing circles is kinda excessive, but makes sense for regulating a whole window manager running in a pygame/sdl window.