26 Oct 2008
For quite a while now, I’ve been rather unsatisfied with the code behind this site. It worked, sure, but that is not a very high standard to aspire to (at least, not if you can set the specifications and the deadline yourself). I recently rewrote the whole thing in web.py, which was much more accommodating of my ideosyncracies, and doesn’t break its API at every minor release.
The original site was based on Pylons, which bills itself as “Rails-like”, “fast” and “fun”. Despite these monikers, it actually looked fairly decent. It’s based on WSGI, which is at least some sort of standard, and it supports using pretty much whatever major package you like for e.g. templating or routing. Unfortunately, it still manages to be a real framework – well-suited to database-backed CRUD, but rather inflexible. And for this particular site, database-backed CRUD is not what I needed.
This was forgiveable, though: I didn’t really want to rewrite the whole thing, and Pylons could be hacked to behave. Well, sort of (I never got caching to work outside of the context of a request, which made clients wait for a Markdown run that could have been done at a more opportune time).
However, a look at Pylons 0.9.7 led me to believe that I’d need to do quite a bit of work to get my code working again (despite optimistic stories). I don’t want to base important (this website isn’t exactly high-traffic, but still a highly-visible part of my online presence) code on such a moving target. And shipping insecure code is hard to forgive.
All in all, it was time to leave Pylons behind. One rewrite in web.py later, the whole thing runs smoothly, in less code, and caching actually works properly now. Of course, web.py has its own downsides, but at least it’s easy to ignore parts I don’t like, like the templating engine (I stuck with Mako and Markdown). Plus, it’s actually documented – sparsely, but a very significant portion of Pylons is completely undocumented.