TechPostsFromX on Nostr: Implementation frameworks are canned bits of design optimized for a general case. ...

Implementation frameworks are canned bits of design optimized for a general case. When used in a specific case, they always add complexity because they handle eventualities that will never occur in your application. Unnecessary complexity is never a good thing.

Even worse, the frameworks' architectures often dominate the application. When you look at the code, what you see is the framework with intelligent warts hanging off of it. I want the inverse of that. At the highest level, I want to see the domain of the problem and the structure of the solution to that problem. I want the implementation details so well hidden that when I look at the top level, I don't see those details.

Finally, I, at least, almost always end up banging against something I need to do that the framework can't do. Crafting a workaround is always difficult and sometimes impossible. Frameworks are closed systems, often with zero extensibility or flexibility built in.

Of course, we want to leverage code and capabilities that others have written. That doesn't mean that we need an all-encompassing framework, however. For example, I'd much rather use a small stand-alone security library than a huge framework that happens to have a security aspect.


Source: x.com/allenholub/status/1848047153932910662