This shows up with restrictions like that you can't mix and match components with different versions of React in the same tree.
Most people view libraries as tools which target narrowly scoped sub-problems of a given solution/application. In React's case, it's a view library -- the V in MVC, for instance. Frameworks are generally considered holistic set of tools which tightly integrate together to form a structured & opinionated approach to the larger solution, e.g the entire MVC approach.
React is widely considered a library. React doesn't tell you how to structure your project, manage its backend communication, handle application state, routing, etc. React is just...not a framework. For any standard notion of what engineers mean when using the term. If you use IoC to distinguish libs/frameworks, you're going to confuse the hell outta people. There are certainly technologies which straddle the line between these terms, but React is not one of them.
Technically it doesn't, but the conventions that grew around it and the availability of learning material effectively produced same default choices, making it a framework via convention.
And I see it as a good thing, because having several competing router implementations is an unnecessary headache.
The React crowd would do good to stop being in denial about this.
I think React doc, by calling Next a framework, is referring to a set of practices and protocols. But different usage of same nomenclature in the same discipline is very common.
Yes? If you create a React component, it does nothing. You define the lifecycle when you call ReactDOM. But you don't need to call ReactDOM. Call whatever you want.