Pensieri di un lunatico minore

The Trouble with Frameworks

Everyone loves a “good framework”, even if they do tend to multiply uncontrollably. Frameworks provide a starting point; a place to hang your code initially, while you’re still trying to figure out what’s going on. The web seems to have more frameworks-per-capita than anywhere else, but that doesn’t mean it has anything that fits your specific needs. Brandon Bloom writes about his experiences with Django, and why he’s been slowing dropping it. I feel his pain.

To me, there are a couple reasons to use frameworks.

First, frameworks fill in all the fiddly bits around the edges of our work. What you’re building, when you’re building a website, isn’t a URL dispatcher, or an authentication engine. You’re not building an ORM, nor are you building middleware. All of that is simply the foundation upon which you build your work.

Next, frameworks jumpstart your work. By providing you with a starting point, you can focus more on the actual interesting work and not so much on the grunt work of just getting things up on the web. This is a great thing, at least initially.

Finally, frameworks provide a way to think about a problem. Staring at a clean white sheet of paper is the most intimidating thing in the world. Frameworks put down a huge chunk of best-practices and assumptions that can really help you think about the problem at hand.

None of this, however, means that frameworks are forever. Frameworks only work if they fit what you need, and often that’s not true as you dig further and further into the problem domain. This isn’t to say they don’t serve a purpose. Django has gotten me running with a bunch of projects, and generally stayed out of the way. It isn’t perfect, and neither is any other framework. The important thing in all projects is to continually re-evaluate your assumptions, and that includes choice of frameworks.

At the end, the knowledge in your application-specific problem domain is where all the value is, not the framework. You can translate it to a new framework, or remove pieces of the framework if you need to. I would, however, make sure you understand why you’re replacing something, rather than just choosing to be different. Every line of code you write, is another line of code you’re solely responsible for. Sometimes a 80-90% solution with hundreds of developers is better than a 99% solution with one.