&gt;<i>Complexity requires structure in order to be maintainable.</i><p>Structure is the job of the lead programmer(s), not some third party framework developer. And it should suit the specific job.<p>It&#x27;s as if we forgotten that programs have to be designed with an overall architecture based on our business, and instead just download off the shelve scaffoldings and try to adapt our business logic around their design.<p>You know that Joe Armstrong quote about OOP?<p>&quot;the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle&quot;<p>Well, it&#x27;s the same with frameworks. You wanted a router, a template engine, and a few more pieces, but you go that, a banana, the entire jungle, and a mustachioed dictator telling you how to do things.<p>&gt;<i>If you don&#x27;t understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position.</i><p>It&#x27;s as if we&#x27;ve forgotten the existence of libraries and APIs, of which there are like 200.000 in npm, and 50 of them are also really good.<p>&gt;<i>Both are signs of inexperience.</i><p>Some of the most experienced programmers, of 20+ years of career of successful projects, don&#x27;t trust frameworks (and surely neither the &quot;framework du jour&quot; of JS, nor the &quot;framework that ate Cincinnati&quot; approach of J2EE of yore).