For the love of frameworks

Most developers have strong feelings on frameworks.

I’ve noticed that the fervor typically associated with languages has transferred to frameworks. We have conferences and meetups around frameworks now. This was inevitable: given sufficiently powerful languages, frameworks are mini-languages unto themselves. In fact, frameworks can put languages on the map! Ruby made such a big splash because of Rails. Thus, framework development is very similar to programming language development, just at a higher conceptual level.

But as the line between language and framework continues to blur, the tendency is to treat the framework as an equal to the language; namely, that it is required. This is a harmful myopia. My worry stems from the fact that it is easy to use the framework as a design crutch. Instead of making intentional decisions about how to structure an app, you outsource the architecture to a piece of code you don’t control. In the process, you’re also conceding part of your design budget to the framework which will be very costly to regain in the future. More importantly, your own ability to design will atrophy from lack of use.

This doesn’t mean you shouldn’t use frameworks. It means they should be a calculated cost, and seen for what they are: commoditized, rapid application development tools. But they are both volatile and ephemeral. And they do not automatically confer a good architecture on your application. Frameworks merely give it a safe, one-size-fits-all design. Generally, the more simple your problem is, the more likely you can use a framework to handle it.