these things are hard, maybe impossible to define.
For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.
For example I mostly agree with your calls/called definition but you also get self-described libraries like React giving you defined structure and hooks that call your code.
Library is something that can be pulled off project and replaced with something else. There's no non-trivial project where replacing React with anything would be possible. Every React web app is built around React.
Id maybe concede that frameworks are a subset of libraries. You can use most frameworks in a library fashion, but the opposite is not true (you'd need a mini framework)
Framework can be more or less modular, Angular or Ember choose to be 'battery included', while React choose to be more modular, which is simply choosing the other end of the spectrum on the convenience-versus-flexibility tradeoff.
React ostensibly only care about rendering, but in a way that force you to structure your whole data flow and routing according to its rules (lifecycle events or the 'rules of hooks', avoiding mutating data structures); No matter what they say on the official website, that's 100% framework territory.
Lodash or Moment.js, those are actual bona fide libraries, and nobody ever asked whether to use Vue, Angular or Moment.js, or what version of moment-js-router they should use.
I think you can probably see that distinction already, but to spell it out React is described as a library precisely because it does just one thing - the view - and leaves it to you to figure out the entirety of the rest of the stack / structure of your app.
Framework, at least to me, but I also believe commonly, means something that lets you build a full application end to end using it.
You can't do that with React unless your app is just something that lives in the browser either in-memory or with some localstorage backing or something. If that's your app, then probably I'd agree React is your framework per se, but that's hardly ever the case.
By the way, back to my original point, I still do think these things are impossible to define and in lots of ways these terms don't matter - if it's a framework for you, it's a framework - but I just had to defend my position since you described it as absurd :-)
It introduces JSX, which is technically speaking its own programming language independent of JavaScript.
It defines hooks like useState() and useContext() for state management, meaning it is not UI only, plus "function based" components that act as a pseudo DSL that is pretending to be functional JavaScript (which it isn't).
Most of the time you're expected to render the entire page body via react.
You couldn't get further away from the idea of a library.
The later stuff adds other ways of doing the same thing but a library it remains.
That's as self described by the React team, and I think the consensus more broadly.
React's Wikipedia page says "React ... is a free and open-source front-end JavaScript library", and has no mention of Framework.
Why die on a hill that it "is" something it says it isn't?
There's plenty of guru who say that they are the reincarnation of Jesus and/or Buddha, doesn't mean that we have to take their word for it.
In the same vein, North Korea is officially the "Democratic People's Republic of Korea", even though it's obviously not a democracy.
Because I think they're wrong about that.
If you'd prefer a different metaphor this is windmill I will tilt at.
To provide a little more of a rationale: React code calls the code I write - the JSX and the handlers and suchlike.
It's also pretty uncommon to see React used at the same time as other non-React libraries that handle UI stuff.
Most importantly, the culture and ecosystem of React is one of a framework. You chose React at the start of a project and it then affects everything else you build afterwards.
In another comment I used the example of rails as a kind of canonical 'framework' that can potentially do everything for you full stack, and django is in the same category, juxtaposed against something like React that cannot.
To that, I think your last paragraph is the one I agree with most closely. It's true, but only for the view part of the app, right? I think that's where I get stuck on stretching to calling it a framework.
I guess I can see it if you're defining your view/client as a separate logical entity from the rest of the stack. Which is totally reasonable. But I guess just not how I think about it.