I see these terms tossed around a lot. I've Googled them myself but the explanations I find are very cryptic. Would anyone mind explaining (simply if possible) what the differences are?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (22)
A library augments code. Ie it adds capabilities.
A frameworks provides the foundation of all your code.
If a library breaks, parts of your codebase may break but the overall codebase will likely still function.
If a framework breaks, nothing will work.
Changing a libraries is low-impact. Changing a framework usually requires a full rewrite.
"Changing a framework usually requires a full rewrite"
This hits the spot.
I have tried to explain this in the past by highlighting restrictions placed by frameworks which business logic need to follow, failing which your code won't work as expected. And that governs most of your app.
Example for front end frameworks, you need to know the event lifecycle (methods or hooks) to place certain code at the right places for certain tasks.
Whereas with libraries, it's opposite, the lifecycle of each part of the app/site is in your control (not the library's) and you call the library like a function call, from wherever you decide to call it from.
However this didn't strike home for many. Your explanation is more concise and better.
"iT's JuSt A lIbRaRy"
Seems to be a common marketing tactic employed by framework Dev Rels to increase adoption.
Unfortunately, that's where a lot the confusion stems from.
Adopting a framework comes with real costs and constraints that should be considered.
The most succinct way I've heard it described is that "you use libraries, but frameworks use you". You can add a library to your project to handle some piece of functionality, but you're still organizing and designing the solution yourself. When you use a framework, everything already fits a regimented pattern, and you're just filling out logic within this already rigid structure.
This makes sense for huge complicated concerns where frameworks like Django or Ruby on Rails dominate - a lot of applications will cover more or less the same basic set of functionality, and it's a pretty complicated set of stuff. These frameworks take care of all that stuff for you, as long as your application fits the mold, so you can spend your time actually coding for the problem.
Thanks for the reply. I haven't any experience with jQuery yet but that's good to know. So, what would things like CSS Grid, Flexbox or bootstrap be considered? Would those be frameworks? I ask these specifically because I've experimented with them and I want to have my terminology correct when I discuss with other developers.
It's tough because it's a little bit nebulous. CSS Grid and Flexbox are actually neither - instead, they're APIs, or sets of functions that are available for developers to use. They are modules built right in to browsers, so they work more like a built-in feature of the CSS language than an external library.
Bootstrap is a little tricky. I'd call it a library, and the website describes itself as a component library, because you can pick and choose pieces from it to include in your app however you like. However, I believe Bootstrap use often ends up using some pretty strict patterns, in order to fully utilize what it offers, so it's used a lot more like a framework. React.js is another tool like this that kind of straddles the line. It's just a library, but in reality it to get the most of it you're better off sticking to the pattern they impose, so it's really a framework-y style of development.
Thanks for the succinct response. I didn't think to consider them API's. I still have a lot to learn!
Don't we all :)
Let's take baking cake as an example.
Library
You bake your cake on your own, but you probably not going to grow the strawberry which is your ingredients, so you buy it from stores(library)
You control the whole process of baking(programming) to bake a cake(program)
Framework
In this case, you get a cake by buying it from bakery.
In this case, you can decide only few things like the color, flavour or design. The whole process will be controlled by Baker(framework)
Hope this can help you understand it better. ^^
All the responses are good in their own ways, so I'll go for brevity.
A library is a component doing a specific task, and you can use it wherever you want.
A framework is a bunch of libraries PLUS an opinionated way to use them, to reduce the boilerplate you have to write.
Typically if you are writing a project from scratch and you install just a library, your software does nothing. But if you install a framework you'll have already something working, like a website with a homepage and a login system.
The basic difference between framework and library is
Framework is a bunch of libraries implemented together to build an application. Example: Angular
Library is a package dedicated to solve specific task. Example: jQuery
That's good on the surface. Now apply it to the ReactJS (library) vs. Angular (framework) scenario.
Gets a bit hazy, eh? :)
More on that: dev.to/renannobile/why-is-react-a-...
I view library in the traditional sense. It has books/functions/modules that you can/might not use.
And a framework like a “frame of mind”. Your house was built within a framework and there are certain things you need to do within that framework and those guidelines to build it right
In addition the already great answers the best way that I've heard it put is that a framework is an extention of the language where a library is like a chunk of code that you bring in instead of writing.
If the maintainers call it a library, it's a library.
If the maintainers call it a framework, it's a framework.
🤣
I would say they have in common to deal with one specific topic.
Depending on the level of abstraction you either call it framework or library.
Say you have code dealing with web requests, you are looking at a request library.
Say you have code dealing with authorization, you are looking at an auth library.
Say you have code dealing with database related things, you are looking at a db library.
If you have code dealing with building web applications, you are looking at a web framework.
From what was said, it is easy to see that a web framework itself could consist of several libraries, e.g. request, auth and db.
OTOH, I assume those terms emerged somewhere in time and there was no clear definition in the first place.