The corollary to this is: *Use* libraries, not frameworks Similar to the case of writing, this isn't absolute. But when you decide to use a framework in y

The corollary to this is: *Use* libraries, not frameworks Similar to the case of writing, this isn't absolute. But when you decide to use a framework in your project, you are accepting a set of limitations and should do it with your eyes open. Unfortunately, framework authors make this difficult. It's understandable but frameworks spend a lot of effort promoting their "pros" to developers and none on clarifying their "cons" (well, typically). When you adopt a third-party framework for a project, you want to do an analysis of the longer-term implications of the limitations the framework. Sometimes that analysis is easy. E.g., if I am making an "event" app -- like an app for "XYZ's 2021 Comedy Tour" -- there isn't a long term (though there, it makes sense to take it further and see if there's an even more restrictive "template" app that will still nicely meet requirements). But if you are hoping to extend and build-out your app/project/solution over time, especially if you don't know details of how, up-front, it's tough to accept the limitations of a framework.