[strictfp]

I disagree with the problem statement; that the framework is trying to solve a meta-problem.

The problem with frameworks is instead that they assume that they're in control. They're the program, you're just writing a plugin.

This makes it unnecessarily hard to use them in all but the most straight-forward use cases. And they're usually also trying to do too much; config for starting, special way of testing, incompatible with other frameworks and libs etc.

Contrary to that, a library does one thing and one thing well. Like a Unix tool. Much easier to use, better coverage, and usually easy to combine. And you can plug them in anywhere.

Frameworks are overreaching, but not in the way that the article paints it.

[grumpyprole]

Yes this is possibly why the author renamed the post. There certainly has been a problem of over-abstraction in the industry, with some of the most guilty parties being the frameworks (e.g. the infamous AbstractSingletonProxyFactoryBean from the Spring framework).

[strictfp]

Maybe. But that specific overabstraction is in the implementation of the framework. It's trying to proxy all the method calls to objects to perform logic around them. It is true that Spring wants the developer to configure auxiliary logic that gets applied around the written code, instead of actually calling that logic. So perhaps that's what the author was getting at.

[grumpyprole]

I think of frameworks as essentially higher order functions, e.g. map/reduce, where one provides the function parameters. That many frameworks seem much more complicated than this is certainly not a good thing.

[hot_gril]

There are still good frameworks that don't take unnecessary control. I think the most common bad ones have some ulterior lock-in motive, usually some company trying to extend its influence, and you have to look out for that.