Earlier quoted context omitted.
I would say the traditional distinction between a library and a framework, to the extent that the industry has any settled definition for these terms at all, is about who dictates the application architecture and the control flow. A framework typically establishes a runtime environment and then calls into your code to respond to specific events. Common examples are GUI applications that run an event loop responding t…
I think you’re being too pedantic. In 99% of React apps, React “establishes a runtime environment and then calls into your code to respond to specific events”, as you put it.
I don't know what the true proportion is, but obviously a lot of people do choose to use React that way. This has never been in dispute.
My point is that you don’t have to. You can keep things simple with React and keep responsibilities cleanly separated within your code. If you do, you will never have a lot of the problems that people who choose to tangle everything together within their React components can run into.
This whole discussion is about whether modern web development practices are good practices, so I think that’s a fair point to make regardless of how many people currently choose to do things the other way.