When writing a software system, you face engineering tradeoffs, such as, how performant or reliable the system must be, how easy it must be to configure, how we

When writing a software system, you face engineering tradeoffs, such as, how performant or reliable the system must be, how easy it must be to configure, how well documented it must be, under what conditions it needs to work, and so on. Furthermore, different components might have different requirements. I think main problem with frameworks is that the engineering tradeoffs involved are not clearly stated. Many frameworks aim to solve all of them, and just let you "configure it as you need", but that is foolish. It's like when a scientific theory tries to explain everything, it cannot provide any prediction, because it cannot generalize at all from the data, as every deviation needs to be explained somehow. In the same way, a "universal framework" is an empty shell that, while it can be configured to do anything you want, the configuration itself becomes the work you would have to do, to tie the specific things you want to do in your system together. However, now you're doing it in framework's DSL and not the same language in which you wrote the specific things. This is a trap that many frameworks seem to fall into. So if the framework you use is too universal, it doesn't add much value, which has to come from dealing with product-specific problems. Some contrast frameworks with libraries, where it is much harder to fall into this trap. If you add a library to your system, you have a good reason, it has to provide some value to justify itself. But framework is by definition the thing on which everything is supposed to stand on, so it's much easier for a kind of inversion happening and instead of framework supporting your software, it's your program that supports the framework. I think what frameworkless movement wants is to have every product/system have its own framework, in the sense, the system's purpose determine what will the framework look like. I.e. your system is the one tying everything together (it just calls libraries for things), not some framework "alienated" from the problem you're trying to solve. I am not sure I entirely agree but I think they have a point. I suspect it is possible to create a framework, but one has to be extremely aware of the interoperability requirements. Creating a framework is like creating an operating system, an environment where application programs run. And it's very good question, then, why use framework, as another layer from the operating system? Why not integrate with the OS itself? What does it bring to the table?