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

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.

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.

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

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.

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.

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.

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.

I wish I had something to argue on this, but I don't. Generally, outside the interpreted language world, it is much easier:

• Libraries are usually separate binary code parts which you can use by linking to them.
• Frameworks are the source component of libraries, they are built into your application (which usually uses a lot of framework functionality to rectify that).

Examples:

• My libvldmail is a library: All of its code is already there, you can just add it and you're done.
• Crow is a framework: You can build an application on top of it.

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.

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.

Yes.

In my opinion, framework is a library which guide you to complete a specified task.

For example, spring framework provides specific syntax such as annotation, structure or syntax for developers to follow and then developers can complete the tasks.

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!

I think React could be a library if it were only used for HTML rendering. However once you start layering on component-based design, state mgmt and props, JSX, etc., it starts crossing into framework territory.

React can still be used as a library when you use a design pattern like MVU. For example, you can accomplish this with Fable-Elmish. At one point Fable-Elmish had multiple HTML renderers available, including React. (If you can swap it out, that is a good sign.) I think the other renderers are no longer maintained because React exists and does a decent job.

Anyway, I completely agree with K's assessment about framework vs library.

Every time I see a tutorial, or anything related to React, it comes with the whole ecossystem that it uses: react-router, redux and some other libraries.

To me, this "group" is a framework. React standalone might be a library, but it's not used as such.

A library is a set of invocable code. That's an easy one.

A framework is a set of rules, ideas and beliefs that is accepted as the basis for building upon. That's a general definition but it still applies here.

So an application framework has a set of rules, ideas and beliefs. If we can accept it, then we move on and build our application within the framework. This means the framework will then expect us to follow its rules (and API) to define our application Instance and our application code.

Otherwise, without an application framework, we are free to set things up however we feel like. Perhaps that will lead us back to our own past patterns, maybe not.

Over time, some patterns gained such wide acceptance that they became the features of popular new languages.
Eg. C++ derived classes from a particular module pattern in C.
Eg. MVC was a pattern in web programming before Ruby baked it in as language features

I moved on to patterns, but let's get back to frameworks. I'm sure there are many other types of frameworks, not just those that deal with the application.
Eg. CSS frameworks.
Eg. HTML component frameworks

I personally think frameworks are sensible. Why not stand in the shoulders of those who came before us?

Then again, whose to say the next big thing won't come from our best patterns that build upon those before us.