Should you write your own web framework?
Rick, over at Just a Little Python, has an interesting post called Three Reasons Why You Shouldn’t Write Your Own Web Framework. It covers some topics that I’ve been thinking about, and is definitely worth reading.
In his post, he makes the case that when faced with the task of using a web framework (assuming you are using Python) and none of the existing frameworks meet your criteria, you should not write your own. Instead, you should add the functionality you need to one of the existing frameworks. TurboGears and Django are mentioned.
He bases his thesis on three main objections:
Objection 1: It’s a waste of your time, because it’s “a lot less work” to learn and modify an existing framework than to create your own.
Objection 2: It’s a waste of other people’s time because “you generate more work for the next developer trying to decide on a framework.”
Objection 3: Your work has diminished impact because by adding another framework to the mix, potential adopters/users are spread across more projects.
On the contrary, as someone who has noticed the proliferation of Python web frameworks (and chuckled at it), I think that having more options is usually a Good Thing and here’s why…
I answer that it is not necessarily a waste of time to create your own framework; one that does exactly what you want. In fact, it might lead to important innovations in the genre and improve all other projects by means of friendly competition.
Reply to Objection 1: Although it may take a considerable amount of time to generate your own framework, I think it is easy to underestimate the time necessary to learn an existing framework enough to be able to significantly rewrite and contribute to the project. If the existing frameworks only partially meet a developer’s design criteria, the process of learning, modifying, and extending is certainly a non-trivial task! And this assumes that once the changes are made, that they actually get merged into the project (certainly not a given). I posit that it might actually take less time to code your own from the ground up (especially if you need something with limited functionality).
Reply to Objection 2: I assert that it is simply not true that providing people with more options “wastes other people’s time.” This would be similar to saying that no one should have ever created other Linux distributions because Red Hat and Slackware already existed! But it was the very action of many distros being created that significant advances in Linux have been made (see Gentoo and Ubuntu Linux). Would we really be better off had no one ever proposed an alternative in fear that someone might “waste time” trying to decide which one to use? By this reasoning, no one should ever write new books lest our libraries get too large and we are left unable to choose what to read!
Reply to Objection 3: I’ve seen countless open source projects that have been released to the public not as some great evangelical cause to convert the masses, but rather just to share something that is cool. Even a cursory look at Freshmeat.net will show you that although some authors want to spread their software far and wide, it is by no means the rule. In fact, usually the projects that are widely adopted are chosen not for their marketing and publicity, but rather because they work and work well. If you only care about the “impact” and “market share” of your project, I think you might be missing the point.
I really do think that Rick brings up some valid points that need to be considered, and he makes a reasonable argument for the most part.
But unfortunately, I think we would all be worse off if everyone heeded his suggestions.
Linkage: Reddit
I think you have some valid points, but I still have to disagree. But first, I think we can agree that the following two extremes are both bad:
* No one ever writes their own framework
* Everyone writes their own framework
In the first case, everyone’s using Zope (not that there’s anything wrong with that), and in the second, well, why use a framework at all? The purpose of a framework is, after all, to save development time and give you a stable application with less effort than would be required if you did it from scratch.
Now, on to the rebuttals…..
#1 – If you’re writing a tiny, one-off framework, maybe you can do it faster from scratch than by extending something else out there. But when you’re looking at re-implementing 70-80% of something, I think you’re kidding yourself if you think the process will be smoother than contributing to an existing project.
#2 – Providing people with a *reasonable* number of options is fine; confusing them with dozens of “me, too!” frameworks does end up wasting their time. This is mainly written from personal experience. I read the PyWebOff. I tried doing some toy projects in Quixote, Zope, and CherryPy. (Twisted intimidates me a bit right now.) I tried to discern why on earth both Subway and TurboGears existed (and I’m glad to see they’re merging). Having a few, well-differentiated options is a good thing. I think we’re way beyond that by now.
(As to the books argument, I think it’s a little off, at least if you’re talking about fiction. One person’s imagination is, I believe, significantly different enough from anothers’ to justify sharing with another ;-). On the other hand, if you look at business books, you’ll find a few books worth reading and hundreds that do nothing but repeat what the good ones said, poorly.)
#3 – OK, you bring up valid points. A lot of what gets released is not focused on the “impact” and “market share” (or “mindshare”) of the project. But if you are a True Believer ™ in the advancement of the technology, I think you’ll see it move forward faster if we find more ways of cooperating on projects.
There are times when a new framework (or library, etc) is needed. I just don’t think it’s nearly as often as new frameworks are actually created. Some projects have this fairly well under control. You don’t hear too much about libtiff, libc, gcc, zlib, sed, apache, Linux, or samba re-implementations. Maybe it’s the complexity, or the pain threshold to create your own. I don’t know for certain. But I believe that these projects have benefited greatly from the coordinated effort of their developers. Just my $.02
You definitely make some very good points.
I’ll be interested to hear which framework(s) you end up choosing in the future (and why). Keep us posted!
Heh. I just wrote a blog post yesterday about rolling my own framework. I think one of the key points is that a) I understand what’s going on at every stage, and b) I get to make the decisions exactly as they best serve me. On the other hand I do spend time working on the framework that could be spent working on the site instead. :)
Somebody’s been reading Aquinas in between blogs.
Heh!
You might be right! ;)
- John