A well-optimized program is often a consequence of a deep understanding of the problem domain, good scoping, and mindfulness.

It often feels to me like we’ve gone far down the framework road, and frameworks create leaky abstractions. I think frameworks are often understood as saving time, simplifying, and offloading complexity. But they come with a commitment to align your program to the framework’s abstractions. That is a complicated commitment to make, with deep implications, that is hard to unwind.

Many frameworks can be made to solve any problem, which makes things worse. It invites the “when all you’ve got is a hammer, everything looks like a nail” mentality. The quickest route to a solution is no longer the straight path, but to make the appropriate incantations to direct the framework toward that solution, which necessarily becomes more abstract, more complex, and less efficient.

The main point of the framework is to keep developers interchangeable, and therefore suppress wages. All mature industries have things like this: practices that aren't "optimal" (in a very narrow sense), but being standardized means that through competition and economies of scale they are still cheaper than the alternative, better-in-theory solution.

I completely agree. This is the point I make here: https://hackernoon.com/framework-or-language-get-off-my-lawn...