DEV Community

Cover image for What's the difference between a library and a framework?
Ben Halpern
Ben Halpern Subscriber

Posted on

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?

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?

Top comments (41)

Collapse
 
jvanbruegge profile image
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.

Collapse
 
marcus profile image
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.

Collapse
 
bgadrian profile image
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.

onion

Collapse
 
scott_yeatts profile image
Scott Yeatts

Sorry, late to this particular party, but I see a lot of great and thought-out responses, but no clear consistent, general rules (although a few are close to the potentially overly simple/abstract ones I'm going to propose). It's important to get away from 'React vs X', and make this a computer science question that applies to any layer of the app.

The phrase 'plug into' is a little vague, but ultimately what it refers to is the Application Programming interface. Either you call the API to implement your code (framework), or you call the API from your implementation (library)

Building from @kayis 's definitions, I would refine it to:

  • Framework: Presents an API that can only be called from within its own context.
  • Library: Presents an API that can be called from any context.

Libraries you bring in to support your application are still libraries, RIGHT UP UNTIL you introduce state which limits the API calls to a specific context. At that point, you as the developer have created a framework out of the source libraries. It might look like every other implementation, but you can change out any of the source libraries to be unique.

The value proposition of a framework vs a library is also very different. Frameworks emphasize consistency and should be very opinionated. A library emphasizes flexibility and should be very general.

If I inject a library, I should be able to execute library.anyMethodOnItsAPI() in my code.

If I have to execute let framework = library.instantiateAllTheThings() and then after that I have to call framework.anyMethodOnItsAPI() to access the API, it's a framework.

Just my 2 pennies :D

PS: I need to stop writing novels. This post was originally just the 2 bullet points with no clarification at all. Then I started thinking about it. Then I had a giant post... then I had 2 posts. Thinking about it. I think that's where I went wrong :D

Collapse
 
nestedsoftware profile image
Nested Software • Edited

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.

Collapse
 
rhymes profile image
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.

Collapse
 
denmch profile image
Den McHenry

I think of a framework as a culture. There's a certain "X way" to do common things in framework X, both out of community convention but also because it aims to mitigate a lot of common problems by providing ready solutions.

A library is something you can go to as needed, but you don't live there, and you may never see your friends there. You're still friends and socialize in the same subculture, but they check books out from a different library branch and that's fine.

Collapse
 
thomasjunkos profile image
Thomas Junkツ • Edited

The difference between a library and a framework is like the difference between a food processor and more basic kitchen utensils like knives.

Depending on your skillset, timeframe and ordered meal you go with one or the other.

Some good results could be achieved with a thermomix, but some meals require other solutions.

Collapse
 
offendingcommit profile image
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.
Collapse
 
tedhagos profile image
Ted Hagos

A library is like a city map, if you need a location, you can get it from this; it doesn't tell you which route to take though. It doesn't have an opinion on how you should go about it.

A framework on the other hand, is like Waze (or any GPS navigation), not only will it give you the location, it has an opinion on which route you should take. If you don't follow the suggested route, it will keep on nagging you

I think this example is either from one of Kyle Simpson's books or his lectures.

Collapse
 
wolfhoundjesse profile image
Jesse M. Holmes

Using a library is like going to your favorite superstore.
Using a framework means you are the superstore.

Actually, I have a theory that you can debate nearly any claim made in tech (e.g., TDD isn't testing, it's building to specification), so maybe we should just burn down the superstores and get back to work. Ha! I loved reading your comments!