“Why I hate Django”
- Published October 8th, 2008 in Software Eng.
&hlI don’t hate Django. Actually, I find it a very interesting framework that has reached a great level of maturity since version 1.0 hit the shelves. It’s a fast, sleek and well put framework in the likes of Rails. I do prefer Rails over Django but that’s a matter of personal preference (actually, it boils down to preferring Ruby’s neat syntax over Python’s — semantically speaking, they’re both very similar).
Actually, we’ve been using Django a lot on our company to develop certain web products (mainly those that require an extensive admin interface, that Django provides right there on the spot). Overall, we’re platform agnostic but we try to focus on some key technologies to create expertise and advanced know-how.
Cal Henderson, Flickr’s author, went to Googleplex in Mountainview during the Djangocon to show his side of the story — why he “hates” Django and frameworks alike.
Most of the presentation is mostly making fun of it, not exactly complaining. For instance, he says that in real languages (like in Perl) you can format your code text as an ‘S’ while on Python you can’t as it needs the tabs to define scopes. Another funny one is him pointing out that Python developers usually use soft spaces rather than tabs which wastes a lot of disk space.
Overall, the presentation is just a chill out ending for the day but there’s a couple of things that are actually true and need to be pointed out.
The tipping point of a framework — when it begins to deter productivity — is when you need to cross its well defined bounds that speed up the execution of common tasks. This is where frameworks (Rails, Django and many others) can learn a lot. They’re quite modular already but they should be way more. The idea is to easily replace bottlenecks by code that addresses the specific needs and nothing more.
This problem mostly concerns medium-sized applications. Small size applications are fine — put a couple of application servers and it runs fine. Large size applications have tons of layers (Squid, memcached, MySQL clusters, etc..) before actually touching the application server. Medium sized applications, on the other hand, don’t benefit from the hardware resources available to large applications and are way more demanding than their counterpart small-sized ones. Handling 100/150 requests per second without growing horizontally might become a tough task, even worse if you can’t rely on caching mechanisms due to application specific requirements.
Making (white-box) frameworks more modular, ie, layering the architecture in such a way that it’s easy to define the entry points and simply replace them, might be one step in the right direction.
P.S. - Shredding inefficient pieces like REXML is definitely another step in the right direction.
P.P.S - Nothing against REXML’s author, he has contributed way more to Ruby than I did. But it’s darn slow, despite not being its fault — parsing XML using an interpreted language such as Ruby is by nature not that efficient.
Mario,
The Carl Henderson talk was a complete joke, the code text formatting as a “S” and the soft spaces related disk space were a complete nonsense.
BTW, ruby has more problems with spaces that Python, an example: http://lucumr.pocoo.org/cogitations/2008/07/01/whitespace-sensitivity/
About medium-sized applications, I don’t understand what is your point of view. Django and RoR as you know are full stack frameworks, but you’re not forced to use all their stuff(at least with Django).
In Django, a view is as simple function(or callable) that takes a request a must return a response. All the rest can be omitted. You can use alternatives to the rest of the layers.
If you have a large application that have a tons of layers as you said, you must grow horizontal. No language or framework can solve this.
Nuno,
Eheh, I guess I didn’t make it that crystal clear that Cal Henderson’s presentation was a joke. Of course it was. Giving the ‘S’ thing as an example was, of course, a demonstration of such.
As for being more modular and detachable, yes, of course you can use what you want both in Rails or Django. Don’t care about ORM? Connect to MySQL directly. The thing is, not everything is that modular. For instance, the routing system can be changed but that involves a lot of tinkering and monkey patching. Making it more modular would make it easier for one to create its own routing mechanism and dispatch the requests with half the lines of code that are necessary to function for a way broader set of uses.
@Nuno Mariz
had no idea Django had fanatical zealots in Portugal… :D