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.
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.
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.
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.
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.
Indeed. Fixed.
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.
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.