Like factories, frameworks are methods of reducing production costs, but come at the expense of certain aspects of product quality.
Sometimes, that quality/cost tradeoff is desirable, sometimes it's not. The trouble comes if using a factory or framework is the only, or even main, tool in your toolbox, and it ends up getting used for everything.
I'm not sure the expense of reduced quality is even an issue. Just like an (decent quality) spice rack I buy from a store is probably better quality than spice rakes built by most people, an app built on a (decent quality) framework is probably better quality than apps hand built by most people.
> the main tool in your toolbox, and it ends up getting used for everything.
I you get the work done efficiently this may be a good strategy. It may be a worse strategy, to spend a lot of time to find the "perfect" framework and a lot of time to master it, just because it's a better fit for the problem. "Good enough" very often does the trick.
Absolutely. From an engineering standpoint, "good enough" is often the right thing. An essential thing engineers do, after all, is to select appropriate compromises.
Sometimes, that quality/cost tradeoff is desirable, sometimes it's not. The trouble comes if using a factory or framework is the only, or even main, tool in your toolbox, and it ends up getting used for everything.