I’ve previously written about my opinion of how programmers should consider frameworks. I was delighted to hear Robert C Martin express a similar point of view in a Q&A session after his Clean Architecture and Design talk at ITkonekt 2019.
Frameworks are wonderful things. You can get a lot done with a framework. You get a framework like Spring or Rails, or JSF, or JPA. Any of those neat little frameworks. Wonderful. Angular. Lovely things. But, the author of the framework does not know you! And does not care about you. The author of the framework does not understand your problems. He is not writing code to solve your problems. They are writing code to solve their problems. When you use a framework you make an enormeous commitment to that framework. You bind your code to it. In the very worst case you derive from base classes in the framework. The framework author makes no such commitment to you. It is a terribly asymmetric relationship. And as an Architect, if you’re an Architect, or if you’re a Lead Designer, you must be very skeptical of that relationship. Because you should be thinking that this framework is out to screw you. You should be looking very very carefully at how much you bind to it. Read the directions. You know. The documents that the framework author writes. Read those directions but do not follow those directions. Because, the directions that the framework author writes will tell you to couple to the framework intimately. Because he loves the framework. You don’t have to. So then what you do is you put the framework behind an architectural boundary. […] You use it in a very careful way so that one day, when that framework no longer satisfies your needs, you will have options.
Let us programmers continually improve in our craft. I think the specific language choice is far less important than the architectural structure of our programs. We’re so quick to hitch ourselves to things like the “Django Wagon” or the “React Wagon” or the “EF Wagon” without planning for an eventual time when those frameworks hinder rather than help.