Having a look at this comment by @kayis from another thread, I'm wondering if you agree with this statement?
...
For further actions, you may consider blocking this person and/or reporting abuse
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.React has a special place in this discussion.
I would like to add a comparison for to your statement "the framework dictates the architecture of your code", for the easier understanding the difference between them:
By that principle I think React can be both but it heavily depends on how you use it.
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:
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:
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 callframework.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:
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'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 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.
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!
IMHO. Libraries tend to be low level building blocks you can reuse anywhere irrespectively on design. Framework always affects design of your software, defining style and aspects of application you develop using given framework.
I dare to say that often framework might be synonym of design ...
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.
Every time I see a tutorial, or anything related to React, it comes with the whole ecossystem that it uses:
react-router,reduxand some other libraries.To me, this "group" is a framework. React standalone might be a library, but it's not used as such.
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.
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.
Spring is more than a framework, it's a whole ecosystem: you cannot pick up something from Spring that looks like a library as it comes with the whole Spring ecosystem dependencies. It's not just a set of libraries that "work well together" (as others have written), they depend on each other (and why I avoid anything Spring, just like I avoid frameworks in general)
The situation of spring is very similar to angular, react, vue.
I would say when many people use a framework, the framework would be a ecosystem.
The old definition was:
A library is code you call. A framework is code that calls your code.
React is a library. You know exactly where you call it and what it does. It is called at that one point where you call React.createComponent.
Other packages are frameworks which do far more magic. You include them and they call your code based on naming conventions or callbacks which you setup, but you don't control when. That is what makes them a framework.
Yeah, A Framework is "something" that calls your code while a library is something you call in your code. But React is an interesting one, I have a hard time believing it as a library since it inherits many properties of a framework such as Angular.
A framework does a lot of things well.
A library does one thing well.
Rails is a framework.
Phoenix is a framework.
OTP is a framework.
React is a library.
Momentjs is a library.
HTTPoison is a library.
Agreed. A framework requires code to be structured around it. A good example would be my pygame virtual window manager framework, strazoloid, which i touched on in my post on my gopherspace client.
In example, strazoloid's window class function-based callbacks are time-sensitive, as all rendering and event processing for the windows, desktop class, and window manager, happens in one thread. This means the programmer needs to run lengthy operations in separate threads, and limits the program's structure.
as far as libraries, pygame itself is more a library than a framework, as its API can be used in just about any structure of program in python.
as per writing/using a library vs a framework, it really depends on the task. using a framework just for drawing circles is kinda excessive, but makes sense for regulating a whole window manager running in a pygame/sdl window.
Typically - yes, however, strictly speaking - no. Check ideas of Hexagonal (aka Screaming, Onion, Ports and Adaptors) architecture. There is nothing, that prevents you from plugging framework to your code )
Completely agree with the definition; but as always there's a blurry line. What if a library works with lots of callbacks that you have to put your code into, is it still a library or does it start to become a framework?
React is probably near the blurry line too. I'd call it a "lightweight framework".
Mostly nowadays, a framework is built on / with couple of libraries whether from the vendor or from the OSS.
Example: django is a framework made from its core package plus lots of packages.
So, I could say framework = core library + dozens of other libraries.
React is the framework in the same way as Linux kernel is OS. You kind of need to "cook" it more to get actual framework. And this is its strength and weakness same time.
Using a lib will make your hands hurt much more than your head,
while using a framework will have exactly the opposite effect on you.
Update: Some times using a poor lib will make your hands AND your head hurt just the same.
I agree and would also try to describe it like
Frameworks: Do things for you by having you conform to a structure it knows how to understand.
Libraries: You need to request that it take action. It will expect spicific inputs, even help you create the, but you still must ask.
What's wrong with definition of a framework from wiktionary?
Also, it appears you have software framework in mind, but there are more (css framework, architecture framework, test framework).
I like the idea that framework gives you an environment, while library don't. This is key difference, which also highlighted in your definition as well.
The noob friendly analogy I use is "a hammer vs. a toolbox". Hammer is the library and you use it to put nails in, or out as well depending on the hammer, whereas with the toolbox (framework) you build the whole shelf.
Can't argue with K here, he's definition seems legit. But I'm more used to idea that libraries try to do one thing, while framework tries be as feature complete as possible.
I think In framework you dont have control on how things will be execute in background as its a structure given to you where you put your code according to its rules..
And a library is something you build things with it like jQuery where you have total control on code structure and execution..
Library is build on top of framework which make developer life easier
A framework can be thought of as a library where you need some sort of tool or tool chain to use it. You can simply run a VB script, but you need to compile a VB.NET one.
The distinction makes sense.
I do not have enough knowledge of contemporary Javascript to say for sure that, by those rules, Angular is a framework and and React isn't.
framework is library of libraries to solve varying broader problems with common set of utilities. library is small focused and geared for specific purpose.
A library sits in your code, your code sits in a framework.
For me it has always been a matter of who calls who first.
If my code calls someone else's code, it's a library. If someone else's code runs mine, it's a framework.
No (yes?), React is a framework. Just because some people associate full-service / batteries-included with "framework" doesn't change the definition in the larger context of software architecture.
Yes.