So, why not one of the other popular frameworks? Why not Django? Well, I think it can be summarized by reading this article. Seriously, executing code in another module to read the URLs stored in the module? What? If that's not ugly, I don't know what is. And if that's the sort of code to write with Django, I don't want to use it.
As for Ruby on Rails: Plenty of people love it. I've looked at the Ruby syntax, and found that I feel it is unreadable. Add in the idea of scaffolding, which amounts to generated code that I'm not allowed to modify directly (not without potentially having to rebuild the scaffolding later, thereby discarding my changes), and I have to discount Ruby on Rails entirely.
There's plenty of other options, but I'm not going to devote space to them at this time. I'm happy with TurboGears.
For me, the major question for today is simple: Why shouldn't you roll your own web framework?
The answer is simple: Rolling your own web framework may well be interesting, but it is going to take up a large part of your time and effort, and in the end is likely to have fewer features than the other frameworks out there.
Take a look at some of the tasks you'll need to consider:
- Authentication and Authorization
- Page Caching and Templating
- Form Validation and Handling
- Code snippet reuse (a la ToscaWidgets)
- Java Script library choice and integration
- Database integration (possibly using an object relational mapper)
Now, consider the developer who is selecting a framework to use: In order to choose between any given set of toolkits, a developer has to sit down, review docs, review requirements, experiment with code, see what fits his style best, see what can be done, etc. The worst part about this involves the amount of time wasted. If, somehow, your custom rolled web framework manages to make the shortlist of the developer who's looking around, then your framework is very likely to waste a significant amount of that developer's time, since it's unlikely to be chosen over one of the other frameworks which have already gone past what you wrote.
The above ignores a few other facts that very relevant:
- If you code for a living, then any clients of yours which are deployed on your framework are bound to you. This is great for your income, but terrible for your clients' futures. If something happens to you, who else can pick up where you've left off?
- Any bugs are entirely up to you to resolve. You cannot ask for help, since no one else knows your framework. The only way you manage to change this item is if you somehow make it enough of a success to be noticed. This might be harder to do than writing the code, especially if you're not a marketing expert.
- Any new features are also entirely up to you to implement. It's all your framework. Until you reach that critical mass, nobody else will help you. And getting to that critical mass produces the classic chicken and egg problem.
Are you doing it to better the state of the frameworks out there? Has anybody else done anything similar enough? Can your ideas be implemented in someone else's framework? Will your ideas be accepted in that framework when brought to fruition? Would forking an existing project be a better answer than starting from scratch?
These are all questions you must answer. You might find yourself making a new framework, and have very good reasons for doing so, but make sure. Consider contributing to one of the existing ones if at all possible.
Who knows, I might be lucky enough to find you contributing to TurboGears itself. I hope to see you on the IRC channel sometime soon.