The argument for the current generation of web frameworks is that a small team can now build in three months what used to take a large one a year. That claim is broadly true, which is why the arguments about it get so heated.

The mechanism is that the framework has already decided most things. Where files live. What a class maps to in the database. How a request finds the code that handles it. How the address bar relates to anything. None of those decisions are interesting, all of them have to be made, and a team making them from scratch will spend weeks arguing and arrive somewhere no better than the default.

Take the decisions away and the first ninety percent of a project moves extraordinarily fast. Scaffolding a working application with records you can create and edit takes an afternoon rather than a fortnight, and it is genuinely startling the first time you watch it.

The bill arrives on the last ten percent, and it arrives all at once.

Everything the framework assumed is now a wall. The database layer expects one table per class with a numeric identifier, which is fine until you inherit a schema built in 1997 by somebody with different opinions about primary keys. Then you are not writing your application any more. You are writing arguments against the framework, in the framework’s own language, and every one of those arguments is code that a new developer will find baffling because it exists to undo something invisible.

There is a second cost that shows up later. The conventions are the documentation. When somebody joins, the framework knowledge transfers instantly and the local exceptions do not, and the local exceptions are where all the bugs live.

What I would say in defence of all of it is that most projects never reach that wall, and the ones you hear complaining are the ones that succeeded. A project that dies in month four never finds out that its data model does not scale. The loud complaints about frameworks come almost entirely from people whose applications got large enough to have problems, which is a filtered sample being read as a general warning.

So the sensible position is boring. Use the framework, accept its opinions completely rather than half of them, and understand that you are trading a cheap start for an expensive middle. If your application never gets big enough to reach the middle, you got the better end of that deal, and most applications do not get big.