The key difference between a library and a framework is "Inversion of Control". When you call a method from a library, you are in control. But with a framework, the control is inverted: the framework calls you. When you using a library, you are in charge of the flow of the application. You choose when and where to call the library. When you use a framework, the framework is in charge of the flow. It provides some places for you to plug in your code, but it calls the code you plugged in as needed.
Imagine trying to make a car. With a framework, you’re essentially given all the materials to make that car, and it’s up to you in what arrangement you put them in. A framework is just like a factory, it is pre-equipped with code that can help you make your product without you thinking about the small details and configurations.
With a library, on the other hand, you start with essentially nothing. The library’s materials are a limited set in comparison to a framework’s materials, and you can pick/choose when you want to use them and when you want to step outside that and use third-party materials.
A library is just a collection of class definitions. The reason behind is simply code reuse, i.e. get the code that has already been written by other developers. The classes and methods normally define specific operations in a domain specific area. For example, there are some libraries of mathematics which can let developer just call the function without redo the implementation of how an algorithm works.
In framework, all the control flow is already there, and there's a bunch of predefined white spots that you should fill out with your code. A framework is normally more complex. It defines a skeleton where the application defines its own features to fill out the skeleton. In this way, your code will be called by the framework when appropriately. The benefit is that developers do not need to worry about if a design is good or not, but just about implementing domain specific functions.
Both of them defined API, which is used for programmers to use. To put those together, we can think of a library as a certain function of an application, a framework as the skeleton of the application, and an API is connector to put those together. A typical development process normally starts with a framework, and fill out functions defined in libraries through API.
Top comments (8)
I had never thought of it as IoC. That is a really interesting way of looking at it. I have generally thought of a framework as “If you do these things, in these ways, you will get these features.” And a library as “Here are a bunch of features, use them however you want.” Thanks for the different perspective.
Thank you Kevin
I don't get and from what I understand I don't agree.
I'm a bit old school here but for me the difference is size and coverage. You had the framework mostlycorrect. A set of api that help you build software. If I would go from largest set to small assigned with low to high offering, then first the SDK then the framework and then the library. The library is a much more focused component. The question is then what is the difference between SDK and framework? I think the reason we don't see much of the difference any longer is that Frameworks are not necessary because we don't build monoliths any longer. A framework was something on top of e.g. .net and would try to formalize some patterns while offering simplified solutions and taking care of some nuances like logging. As I said, we don't need them any longer and the SDK's nowadays include some of those responsibilities like e.g. middleware hence .net Framework.
Also, not everything should be related with real life examples because they can fail as much as they intend to help.
Frameworks are of course still used. Especially in the Java "backend" world there is en.wikipedia.org/wiki/Spring_Frame... and the description fits.
You build your (hopefully) tiny classes, that you can declare as Controller, Service or other and then the framework knows when to call this piece of code.
A library is something else. You can use a library to not write a method again, that already has been written and is either trivial (apache string utils) or very hard to write (encryption libraries). The difference: You call StringUtils.split and then continue with the result in your code. In a framework, you just compute results and the framework will take this result and do stuff with it.
I'm not sure the classifications are respected. Hence the fact that the lines have greyed out incredibly.
But if I read you well you make the distinction between writing code and not to utilize a provided functionality by a 3rd party. With that in mind, almost everything is a framework nowadays. Not disagreeing but fact is at this point that the lines have faded away. If for whatever reason you pass a predicate or an interface to a library function then what is it then?
Higher order functions (where you pass your own methods) are an interesting case. You plug in your code to then get the result for processing in your own code. So a framework inside a library.
So... yes, the lines are not that well defined and probably never were.
The general idea is still valid: If I am controlling the program flow, I am using libraries. If I am writing code to be plugged in somewhere I am using a framework. Might it be nodejs, .NET, Magento or Spring (Boot).
It is important to have the difference in mind. Especially when starting your live as a professional programmer. The inversion of control is what makes programs (frameworks) reusable and (more importantly) easy to change. Easy changes are so damn important these days...
There used to be frameworks (meaning I needed to write code) where the implementation with e.g. a class inheritance was kind of empty. Yet another blurry line. Any kind of code always controls the flow and I can't relate to this distinction.
If you ask me from my Dev years experience, I like your distinction because it kind of matches my practical understanding. I would consider a library something simple though potentially difficult, something were I don't 'care" about what happened inside and hence I need to log around it. I use the term log not at logging but at control and verification. At the moment I become too much involved with what happened then I'm out of a library concept. Maybe in other words, if I inject my code flow in the flow of what I consume then its not a library any longer. But then what about aggregator functions etc?
Again I'm not offering an official explanation but my personal interpretation. Nowadays I can't really place on either side with respect to some libraries, frameworks and components. With the exception of some clear libraries, everything else has become to mixed. At this moment I consider libraries stuff like a powershell module or aws toolkit etc. The code invocation does something compete for which I only care about the success very similar to an API call. I only need to control the flow some the 3rd party invocation.
I really like this perspective but React JS is still not a framework, right?