Caffeinated Simpleton

Last year when I was going through the various python frameworks, I eventually dismissed Django in favor of TurboGears. From TurboGears I settled on Pylons as my web framework of choice, and excepting some quirks and some bad documentation, I’ve been very happy.

Last night I had the privledge of revisiting Django to do a programming problem as part of an interview. I was tasked with making a little blog system that supported pingbacks. Having a lot more experience with frameworks now, I was able to really sit back and think about what I liked and what I didn’t, with respect to Pylons.

First of all, the emphasis on loosely coupled components is terriffic. One of the major problems we realized with harmonize was that our componentization was not fine grained enough and required too much knowledge of the code base to effectively navigate. Django is right to emphasize this from the beginning.

Django’s documentation is also quite a bit better organized than Pylons. They have a standardized approach that details all their components, and good tutorials and an alright book. On the other hand, the documentation for pylons is spotty and disorganized, with the documentation for its components being hit and miss. The docs for SQLAlchemy are second to none, but the docs for Beaker, the caching framework shipped with Pylons, barely exist.

The actual components of Django could use some help, however.

Django does not have a robust web server built in, like Pylons, so the recommended deployment strategy is with mod_python and Apache. This is hardly the lightweight, scalable approach that has become popular lately. I feel that an excellent static web server that can also serve as a reverse proxy is a great way of getting the most out of your servers. When developing new apps, you don’t want to be giving huge amounts of memory to apache. Your young app is most likely going to need that memory!

Django’s model is pretty good, but it clearly lacks the power that SQLAlchemy has. SQLAlchemy is an amazing bit of technology with support for everything from programmatically constructing SQL to sharding databases to a fully declarative ORM. Django’s model is just an ORM. I didn’t find querying to be very intuitive either (attributes just magically appear in objects that represent relationships), but it may just be that I am used to SQLAlachemy’s model. SQLAlchemy uses a “session” in a way that makes a lot of sense once you read a bit about it. I never know when Django is flushing transactions because there’s no real concept of a session.

By far the worst part of Django is the templating system. Perhaps I wasn’t using it correctly, but I hated it. After spending all summer with a robust and powerful templating solution in Pylons (Mako), I was completely taken aback at the simplicity and incompleteness of the Django solution. Beyond optimizations like the lack of compiling and caching of templates, the Django system doesn’t even support basic python syntax. You can pass variables, define blocks, and do basic if statements and loops, but beyond that, you can’t actually actually execute any code. Simple things like accessing a single element of a list seemed to be unsupported. I could not import modules or call functions, and forget about blocks of python code.

The syntax itself of the templating system seemed poorly thought out. The template tags did not look like html tags, python code, or the code of any other language. Instead they use “{% %}” to denote blocks and “{{ }}” to denote where the values of variables should be inserted. This seems completely arbitrary. I feel that Mako’s habit of making its syntax look like regular tags is much cleaner and natural.

Finally there was the URL routing system, in which I had to define the route of every URL I wanted. This may have just been my own lack of knowlege, but I really like the Routes strategy (if not Routes itself) in Pylons. Routes just automatically routes urls to a class and function, but allows you to specify custom routes that behave very similarly to Django’s. The difference is that you don’t need to specify a complicated regular expression in the average case. Normally things just work.

Django defends their URL mapper by saying that other solutions are Black Magic and that explicit is better than implicit. I think that’s ridiculous. You can easily look in the routes.py file in a pylons project to see exactly how they achieve their “Magic”. Furthermore, Django uses magic all over their model, both in how objects are constructed and in how you query the model. The Django URL routing could definitely benefit from some useful defaults.

Well, I think that’s all I want to say on the topic right now. Django seems like a very nice framework, and a bit more organized than Pylons. In the end, however, I’ll stick with the superior components Pylons ships with, and maybe try to help them out with their organizational issues.

Because I’ve been doing a lot of web development lately and I have an idea for a site, I’m teaching myself Erlang by building a web site. So far I haven’t learned much erlang, but I am learning a lot about the current state of the Erlang web community, and it’s not pretty.

Coming from the Python world, I’m used to a plethora of high quality, well documented tools to help me with almost any problem. This is not how things work in the Erlang world, particularly when it comes to web development. There’s YAWS, which is a great web server, and that is what defines Erlang web development. YAWS has the ability to process files in a similar manner to PHP, and embedding erlang in HTML used to be the easiest way to do Erlang development. This was up until the emergence of ErlyWeb, which is a crude framework to support Erlang web development. Hurrah, salvation at last, right?

Not really. ErlyWeb is actually an appmod for YAWS, which means you cannot use it with any other web server. YAWS is a very good webserver, so that’s not the end of the world, but a well designed framework should not enforce that restriction. The author also demonstrates on his blog how simple the code for it is, and it is indeed simple. This is at the expense of a great many other things, however. There is no integrated debugging, there is no deployment strategy, there is no debug versus production mode. This is all handled by messing around with YAWS, which is a web server, not a framework. It reminds me of my early PHP-MySQL days, when I had to install a full LAMP stack on my development machine to get anything done.

The basic problem with ErlyWeb, in addition to its lack of documentation, is that it’s not actually a web framework. It’s an MVC abstraction for Erlang. A framework is much more than just providing a basic abstraction, it should also provide the tools necessary to quickly produce web applications. ErlyWeb may do that someday, but it doesn’t now.

There are two problems with this post. The first is that I’ve only been working with ErlyWeb for an afternoon and may be completely wrong. The second is that I should be writing tools to make ErlyWeb better instead of a blog post complaining about it. However, as a guy who doesn’t really know Erlang, improving ErlyWeb would be a bit out of my skill range right now. I need to really understand what i’m getting into first. If I don’t get distracted by something else, though, I’ll certainly have a crack at addressing some of these issues.