This has brought about two more interesting questions:
- What is the difference between a library and a framework?
- Why would you prefer one over the other?
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (26)
A framework is like Ikea furniture, you take it, build something with it, and you have a nice looking thing that is standard, and there are many flavors of the same thing to choose from. But just because you can built a shelf with Ikea's out of the box shelf solutions, doesn't mean you could actually build a nice shelf all by yourself. If you truly understood the principles of carpentry, then you could go to home depot, buy the required items, and make a shelf yourself. Now then, you might think that you don't need to be able to build it from scratch as you can still furnish a room with Ikea furniture. That's true in many cases but what if a client then comes back and says "I like this shelf but I wish it also had LED lighting on the edges." or something silly? You might not know how to make that work. Or someone comes to you, knowing you work with shelfs and needs you to fix theirs. If you can't build one, you won't be able to make a nice solution. You may fix it, but it will not look good and be harder next time(I.E Tech debt). So understanding the framework is very useful.
The library on the other hand, is a small standardized piece of that shelf. Its not a full solution, just a small part, but makes things a bit easier. Maybe home depot in the example above sells the inner pieces of wood that you actually set things on, cut in a standard size that you need, all lacquered and ready to go. Or perhaps the little plastic things you set the shelves on so you can move them and adjust their height instead of using L-brackets. They aren't a full solution, but enough of them fit together to make a framework.
In the end, the basic idea is that "a framework calls your code, you call a library's code" is the measuring stick I've heard and it seems to be true more or less.
BONUS SHELF ROUND:
The L-brackets vs the little plastic shelf stoppers are a good example of dependency injection. The actual shelf doesn't care how you've decided to implement a stopper for it to rest on, just that you have something, these are interchangeable and not coupled with the shelf at all. The same way a class wouldn't care which implementation of a dependency you give it, just that it's given one.
Love your explanation! And the bonus. :D
Love your explanation! 😃
It is easy to understand when it is explained with real examples.
So much furniture to assemble...#Ikeaproblems
Thanks.
Might try and re-work the comment into its own post later. I'm sure if I put a bit more effort into it I could make the idea I'm trying to convey a bit easier to understand. :)
Glad it worked out well for you though!
The top comment from this similar discussion is good.
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
patchfunction to apply a virtual dom description to the real dom. You can then build your architecture how you want.This was commenting on this one:
People have different definitions for library and framework
One definition I know is:
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.
Ultimately you want the right tool for the job. A framework may “lock you in” a bit more with the project’s direction. A library is most likely to do a job which could be replaced later by a different library or your own code.
If you choose a framework, you’re choosing to ride together and really do things the way the framework wants things done.
This is a really important point. Frameworks are usually quite opinionated about code structure, sometimes even requiring files to be in certain directories, etc., and it's worth taking time to learn to work within the structure the framework wants. Trying to take one framework and make it work like a different one is just going to cause more frustration for everyone.
"... usually quite opinionated..."
Nearly always very opinionated in my experience.
Thanks Ben!
I hadn't realised there was a similar discussion already that makes some really great points on this topic.
It’s a topic that deserves plenty of discussions. Lots of great new points here.
Indeed. Fixed.
For me, this basically boils down to:
While I know this is oversimplification, I really don't think that going inside all of this "architecture", "patterns" etc stuff is necessary when talking about such things.
While I like the analogy, I would describe it as completely opposite. A library gives you a single hammer. It's a great hammer but it doesn't work as a screwdriver. You'll have to find one of those yourself. On the other hand, a framework is the already built-house that only allows you to do the interior design.
Thanks for your reply!
I wouldn't say so, for example, look at jQuery. It gives you stuff like
show,hide, its own selector syntax etc. Or, okay, as this may be a bad example, look at Velocity. It's a library with sole purpose of animating stuff. It gives your their syntax, their methods and produces output carefully designed by them.Now look at React. You're basically getting Virtual DOM builder, with some state controls. And quite frankly, they don't care whether you build a button and place it among jQuery ones, a component that will be sold, a web application consisting of thousands of elements. They just give you the tools to do so.
Same is with the wood/house metaphor. You can get hammer, nails etc branded by Facebook or Google and build a house, a single room, or a box. The second option just gives you a house, perhaps it's a small house, perhaps it's just a room, because given library is focused on solving one thing. But it always be a ready-made solution.
I have an unexamined theory that you can't avoid either. Libraries will be more versatile than a framework but frameworks will guide you to implementing a solution. The question ends up being is that the solution you wanted.
A framework is kinda like going to a travel agent and saying: "I want to visit Italy. Can you plan that for me?" This travel agent is known for its Italian vacations, but it gives the same basic itinerary to everyone with a few optional variations. When you are there, if you decide you want to do something different from your itinerary, you have to pay (lose a deposit) for the missed events. Going against the itinerary costs extra money, sometimes significantly.
A library is more like planning your own vacation, perhaps with the help of some online tools. It requires a little more research on your part to discover the events and organize a schedule. But without a pre-arranged appointment, you can decide to skip events or swap them out for others. This flexibility costs more of your time, but not nearly as much as going against the travel agent's itinerary. You can also craft exactly the experience you are looking for. A wine tour? A picnic in the countryside? A walking tour of Rome? It is your choice, and you can change your mind when you get there.
Well, this ended up being an LI5 analogy.
I think both frameworks and library approaches are valid ways to go depending on your goals. I have used lots of frameworks over the years. Nowadays I am only interested in the library approach because maintainability and quality are high priorities. Being locked in to a framework means I eventually have to write hacky, hard-to-maintain code to work around a missing/mismatched framework feature. Because every framework is just someone's opinion on how to solve a set of problems... but a given strategy doesn't work well in every scenario. Also, swapping out a library for a better one is a serious endeavor but it is usually achievable. Swapping a framework is completely intractable, and it usually means a complete rewrite of the app. Still, frameworks can be good for getting your app out quickly. Sometimes this is a higher concern than longevity.
Gotcha! Good examples used 😉
In our industry, I think the terminology is a bit vague as to the differences between a Library and a Framework. I'd also throw in a third term that seems to potentially mean the same thing as Library or Framework: SDK.
In my mind, I tend to think of a Library as a static library linked to the application at compile/link time, whereas a Framework as a dynamic shared library referenced by the application at compile/link time but loaded by the executable loader at runtime.
However, that's just how I use the terms in my head. And they are definitely used differently in other contexts, and other programming languages or toolchains may use those terms as better suited for their environments.
I don't agree (and strongly so) with your representation. Linking an application means that you use tools to bolt together all the components which you need in order to make the application work.
Whether you use static or dynamic linking is irrelevant - you're still using libraries.
A framework, otoh, is an API. It's a (more or less) abstract definition of exposed surfaces between components.
Those that I'm most familiar with are for hardware support in Solaris - the Solaris MultiPathed IO (mpxio) stack. The API/framework in that area is a set of interfaces which driver writers are expected to support, so that software further up the stack (closer to userspace) can use the appropriate function calls and callbacks to do the right thing. Having a [documented, supported] framework allows you, the vendor, to get third parties (Emulex, QLogic, Brocade et al) to write their drivers for your OS, rather than requiring the vendor have those staff in-house and extra lawyers to do the IP licensing dance.
The library implements the framework.
A library is something you add to your project and utilise.
A framework is something you build your project inside.
You can't prefer one over the other, they're not comparable. A framework will use libraries, a library will not use frameworks.
I think something important to point out here, is that a framework dictates the architecture. I see many people against this.
But in my opinion, it can actually be benefit. Every new developer doesn't need to learn from the ground-up the "solution" built by your 2-3 developers. And most of the time, a solution built by the community (thousand of people) will be much better than something built by a few.
And being realistic, clients do not ask crazy stuff. It can probably be built with either a framework or a library.
Cheers!
Library - A set of classes/functions to ease development, for example: lodash, jQuery, React (React itself is just a set of functions and classes).
Framework - A collection of ideas and libraries to make up the structure for your application. These can often include authored libraries/code to fill up the gaps. Examples: Next.js, Ember.js, react-create-app (While react itself is just an individual library, react-create-app is a collection of many different packages and ready to use configurations to make development much easier)
I've made my position clear
Why You Shouldn't Use A Web Framework
David Wickes ・ Jul 26 '18 ・ 4 min read
Thanks David!
Great points made in your post. 🙂
Also, I would like to highlight this comment from Dimitri:
I think you are missing the point.
What I understood is that the author is not saying you should never use any framework ever. (the title is somewhat purposefully misleading I guess).
What I think he meant is:
1/ sometimes you don't need a framework
2/ you should learn how things work "under the hood" before considering using any framework, because frameworks change all the time but the underlying tech does not.
This is true for more contexts than web development by the way.
For me,
I don't agree - an IDE is completely different to either a library or a framework; it provides you with an environment in which you can write/debug/test your implementation of either.
A SDK might be a bit of both worlds here - "here's a collection of libraries for you to use while working on $project, and you should use our Framework/API to structure how you do it" - but it's not imnsho a framework per se.
I keep coming back to: