https://tomasp.net/blog/2015/library-frameworks/ A good comparison can be Qt vs Skia. I agree with most claims of this essay. However, having used many frameworks and after having analyzed why they work well, it boils down to. 1. Good documentation 2. Multiplatform abstraction behind a standard interface 3. Combine many calls into a simple end point (button->draw in Qt vs drawing a button via Skia) If these are addressed by libraries, then libraries with simple callbacks are much more preferrable to frameworks. One problem which frameworks and libraries don't address or hide away is state machines. An app is fundamentally event loop + state machine. Any framework that you use long enough, you will want to peek into how it is actually handling events and customize it.

I think frameworks can change the programming model whereas a library cannot. So a runtime like Akka is really a framework (note also has a state machine abstraction) , but there is no real way you can add the actor model without giving up execution control. Similarly, React gave a declarative programming model to the imperative DOM. Not sure if its possible as a library (it kinda of is a library until you hit the JSX bit) Programming languages don't compose either. I see frameworks as a less drastic version of a language change. They can fundamentally change the whole programming model. They change a programming language into a different programming language, but without changing the syntax (React did change the syntax too tho) or access to the ecosystem libraries. So sometimes a thing needs to be a framework, but you should use the least powerful thing to achieve your needs. If it can be done as a library then do it as a library.