The primary issues that make frameworks flawed

I think the question that is left unanswered here is - if not frameworks, what should we use?

Conceptually, there are only two solutions either:

a - write everything from scratch, which I think we all agree will be disastrous.

or b - compose tons of libraries together - for a typical webapp, that means connecting your ORM library to your routing library, to your template rendering library, to your authorization library, to your authentication library, session management, caching, deployment management, logging, monitoring , etc...

Obviously, the big giant downside is that it takes really long to connect all those things, and you usually do it badly and break abstraction layers anyway (not to mention security).

You end up spending 10 hours on every one of the dozens of things you need to make a proper webapp instead of spending a few hours setting up most of your app with the framework of you choice and spend 30 hours on that 1 or 2 damn situations that don't quite fit into the framework's golden path.

Really, you can work to create better frameworks, but the cost-benefit analysis will always sit with working with a framework rather then joining things together - unless the project is trivially small or you have enough resources to practically build your own framework. And that's before we take into account new hires and the reduced cost of training if they already are familiar with the popular framework you chose to use, or the ability to create plugins/extensions/add-ons to a framework that crosses concerns (For example a plugin that can deal with both add a model and a new route).

You don't need much CS theory in order to develop and maintain a CRUD app. I've been a programmer who gets paid to write code for 11 years now, and I'd say most of the code I've seen wasn't that much complicated than a CRUD app.

Also, I don't feel the need to be called an engineer. I just write code, hoping that it would work most of the time, under as many diverse circumstances as possible and trying to meet the client's needs. It sounds trivial, there's no "theory" in it, but sometimes is hard as hell to do all these 3 things right.

I think this is a case of not knowing what you don't know.

I've found that without a framework, there is very little to actually connect. I use something like spring-context for stateful things like datasources and queue connections, for clean setup/teardown. In the controller, I call a service which returns a plain map with data, and pass that data to a mustache template. I tend to just invoke stuff and pass around data. What is the difference between `mustasche("foo.mustache", myService.baz())` and some implicit render logic a la Rails? One extra line with the template name instead of a framework that implicitly resolves the template?

Setting up a new app usually takes me 10-15 minutes and 100-150 lines of boilerplate (read config files, create spring context, wire up controllers, ...), which is definitely worth the (low) cost in my opinion to achieve the blissful state of absolutely no implicit stuff happening beyond my "main" being invoked. This win gets bigger the more the project grows.

I have to say, I disagree with virtually every conclusion here.

I don't doubt that there are some bad frameworks, or indeed that some developers have a habit of reaching for the closest framework even when it's not the best solution to a particular problem. This was most obviously demonstrated to me once when several applicants for a developer role submitted a simple CLI coding exercise as an entire Rails app, despite the complete lack of that requirement.

We all use abstraction to model problem domains in terms of familiar concepts. There are different levels of these abstractions, and different levels are used in different places where it's appropriate. Sometimes using no framework is suitable; sometimes a small framework is suitable, sometimes a grab-bag of libraries, and sometimes a larger framework.

I've used Rails a lot. In some ways, it's a pretty standard implementation of well-known concepts – REST, Active Record, MVC et al. But it removes the work and friction of selecting an ORM, routing library, template renderer, asset pipeline, session management and so on, instead providing workable standard solutions for all of these. In many cases, this is completely fine – there are a class of web applications that Rails is pretty great for. Using it reduces the amount of custom plumbing that is required, and that can be both a short-term and long-term win.

On the other hand, some applications don't fit into a particular framework's constraints. Building a server to do some basic websocket communication would probably not be a good fit for Rails, for example, and one might consider building it on top of some libraries in Go, or Node, or something else. Maybe sometimes a larger application has specialised requirements that mean a framework would be an unsuitable choice, and it's better to compose modules in a different way. These different scenarios come up all the time!

Avoiding the use of frameworks, in my experience, can often result in developers building their own buggy implementation of 50% of what the framework offers. If the problem exists at all, it exists in the unsuitable usage of frameworks.