I’ve seen the results of blindly rejecting using any framework many times in my career. Very often, it leads to in-house developed frameworks of inferior quality. Bad quality because developers didn’t think their abstractions through well enough (they didn’t need a framework, just a couple of quick hacks), because they run into the same issues framework developers ran into, but without a community of thousands of users that help with testing, propose issues and fixes, etc, etc.

Blindly rejecting frameworks is as short-sighted as blindly accepting any of them. It is important that you select the right one. Certainly, using a bad framework is worse than not using any at all, and sometimes not using a framework is a good choice, as long as you don’t make it a dogma.

The reason I avoid frameworks like the plague, is that whenever someone feel a need to call something a “framework”, it almost automatically follows that they’ve introduced far more coupling than needed. More coupling means less flexibility in replacing components that don’t fit your application, and inevitably leads to people writing a lot of code to work around limitations they wouldn’t have in the first place if they had the freedom to pick the best component for each part of the job. I’ve yet to see a framework for which this doesn’t hold true (I would not have a problem with a framework that was truly just a collection of independent, easily replaceable components)

A typical example in the Rails stack, for example, is the amount of effort people have been putting in to work around scaling issues with ActiveRecord (far more database calls than needed, and lack of proper connection pooling and support for partitioning etc.) rather than just yanking it out and using something more suitable for their apps.

I agree with you that lines of code is a liability, and that is _exactly_ why I disagree with you on frameworks. I’ve yet to come across a single time when using a framework over judiciously combining independent, highly cohesive components into a loosely coupled system would have resulted in less code for me, because picking components lets me get a much better match than trying a one size fits all solution.

It’s not time that’s the issue. In fact, the process of picking the right tools often by itself makes a framework-less process longer than just jumping in with a framework that may or may not fit your needs. It’s more time consuming because you have to make a conscious choice about WHY you’re picking a specific ORM, or a specific template engine, etc. At the same time, each choice is less costly in the long run than picking a framework, because the cost of rewriting the app to replace a component is far lower than the cost of replacing the framework or working around problems in a single component when those problems get severe enough that replacing the component would have been the preferred choice.

I also wildly disagree that using a framework makes the application much easier to understand. On the contrary, frameworks tends to obscure a lot of control flow that I really don’t want obscured. It means that once whichever framework you pick is not the hot new thing anymore, you are going to find that getting developers that happens to know just that framework well becomes increasingly hard, and that’s exactly when you don’t want your application to depend on huge masses of code you can’t quickly and easily get up to speed on.