Python on Rails

Ich bin ein Ruby- und Rails-Liebhaber. Ruby ist die angenehmste Programmiersprache, die mir je über den Weg gelaufen ist, und dennoch außerordentlich mächtig. Flo dagegen ist ein Python-Coder, was natürlich schon zu einigen interessanten Diskussionen geführt hat.

Nachdem sich meine Kenntnisse in Python auf ein Minimum beschränkten, und Flos in Ruby ebenfalls, haben wir nie die kindische Überlegung angefangen, wessen Sprache denn nun “besser” sein könnte. Ebenso mit Rails und Django, dem Rails nachempfundenen Web-Framework für Python.

Jetzt haben wir vor kurzem beschlossen, ein gemeinsames Projekt zu starten und haben uns als Programmiersprache auf Python geeinigt, und weils eine Webanwendung wird, auch auf Django. Und deswegen bin ich seit einer Woche dabei, mich in Python und Django einzuarbeiten. Zeit für einen ersten Vergleich.

Natürlich muss der Leser hier beachten, falls das noch nicht klar geworden ist, dass ich nicht nur Ruby/Rails sehr gern mag, sondern auch erst sehr wenig Einblick in die Innereien von Python/Django gewonnen habe.

Erster Eindruck: Django ist komplizierter als Rails. Zum Beispiel vermisse ich an vielen Stellen die Convention-over-Configuration-Einstellung von Rails. Was wohin gehört ist in Rails erst einmal klar (weil es schon dort ist!), und nur dann wenn ich es anders haben möchte als die Vorgabe, muss ich mir Gedanken machen.

Für jede Django-Funktion und selbst alle Datenbank-Objekte, die ich in meinen Funktionen benutzen möchte, brauche ich eine Zeile am Anfang des Quellcodes. Das ist nicht besonders schlimm, aber ärgert dann doch manchmal, wenn ich erstmal überlegen muss, welche Funktion ich aus welchem Modul holen muss, etc.

from django.http import HttpResponseRedirect
from django.shortcuts import render_to_response, get_object_or_404
from testproject.polls.models import Choice, Poll

Um meiner Django-Applikation klarzumachen, für welche URL sie welche Funktion aufrufen soll, muss ich über einige Regexp-Hürden hüpfen und mir im Voraus überlegen, wo ich eine “generische” und wo eine “angepasste” View benötige. Dieses Stück Code muss ich mir für meine generischen Views selbst zusammenbasten:

(r'^(?P\d+)/results/$’, ‘django.views.generic.list_detail.object_detail’, dict(info_dict, template_name=’polls/results.html’)),

Hier der Vergleich mit dem schon vorgegeben Rails-Code, der zwar nicht genau aber fast das selbe tut (automatische Route zum aufgerufenen Funktionsnamen):

map.connect ':controller/:action/:id'

Insgesamt sind es viele kleine Dinge, die einzeln kaum ins Gewicht fallen, die dann aber in der Kombination vom Code her Rails angenehmer machen.

Vielleicht liegt es ja genau an dieser komplizierteren Codestruktur, dass Django im Vergleich zu Rails so schnell ist. Selbst im Production-Modus auf Apache sind meine Rails-Anwendungen um Größenordnungen langsamer als Django im Development-Webserver.

Natürlich habe ich keine Benchmarks gemacht, aber z.B. fühlt sich http://www.lawrence.com/(Django-Seite) schneller als als http://mephistoblog.com/(Rails-Seite). Nach ein bisschen Graben bin ich aber auch auf einige flinke Rails-Seiten gestoßen, z.B. http://corkd.com/ oder http://www.alistapart.com/.

Es scheint aber doch so zu sein, dass eine Rails-Applikation, die sich schnell anfühlt deutlich schwerer zu erreichen ist, bzw. mehr Know-How verlangt als eine ebensolche Django-Anwendung.

Ein richtig großer Pluspunkt für Django ist das Admin-Menü. In Django wird ein komplettes Admin-Menü mit Benutzerverwaltung, Rechteverwaltung, etc. mitgeliefert, gegen das Rails’ Scaffolding alt aussieht. Hier sind ein paar Screenshots. Gleichzeitig verbraucht diese Funktion keine Ressourcen wenn sie nicht gebraucht wird: Standardmäßig ist sie komplett deaktiviert und kann aber durch das Unkommentieren einer Zeile aktiviert werden.

# 'django.contrib.admin',

Schön! An dieser benutzerfreundlichen und doch mächtigen Lösung könnten sich einige Rails-Plugins, die sich das selbe Ziel ausgesucht haben, vielleicht eine Scheibe abschneiden. Oder vielleicht nicht? Zugegebenermaßen legt sich Django auf einen bestimmten Seitentypus fest:

Developed and used over two years by a fast-moving online-news operation, Django was designed to handle two challenges: the intensive deadlines of a newsroom and the stringent requirements of the experienced Web developers who wrote it.

Tatsächlich sind viele Django-Seiten News von der einen oder anderen Sorte. Ob Django wirklich nur für Seiten dieser Art geeignet ist, oder sich einfach nur so sieht, weiß ich nicht.

Insgesamt macht Rails deutlich mehr “unter der Haube”, und das merkt der Entwickler daran, dass er sich mehr auf die tatsächliche Anwendung konzentrieren kann; Rails belegt, sagen wir, 15% Kopf-Speicher, Python 25%. (Und zum Vergleich: C benötigt meiner Ansicht nach 60% oder mehr.)

Mein persönlicher Schluss ist somit, dass ich lieber Django-Anwendungen benutzen würde, da diese anscheinend dazu tendieren, schneller zu sein. Entwicken würde ich aber lieber Rails-Anwendungen, die machen da dann doch noch mehr Spaß :)