Django: el tercero en discordia
No es la primera vez que lo digo, pero lo repito por si queda algún despistado: estoy evaluando qué framework me viene mejor. Ya analicé CodeIgniter dos veces, una comparándolo con RoR y otra por separado, y ahora le toca a otro igual de bueno: Django.
En principio no me planteaba su inclusión en la lista (en gran parte por Python, del que soy un desconocedor absoluto), pero por motivos laborales se ha tenido muy en cuenta su candidatura, la cual casi me convence. Debido a que Rails me había dejado muy buenas sensaciones, le he enfrentado a este nuevo púgil… Y los resultados no han podido ser mejores. 
Me he inspirado en miles de sitios que me sería imposible referenciar ahora, pero lo que sí debo hacer es enlazar este PDF:
http://3columns.net/habitual/docs/RailsVsDjango.pdf
De él he sacado algunos fragmentos de código y varios conceptos, así que puede que veáis lo mismo en los dos sitios (así como en artículos anteriores de este mismo blog). Llamémoslo tributo, no plagio (además, así lo tenéis traducido 
). 
No me enrollo más y comienzo con el análisis. El formato es el de dilucidar si una afirmación es cierta o no, ya que he visto que hay muchos conceptos que no están claros cuando se habla de estos dos entornos.
3, 2, 1…
Los dos cumplen el modelo MVC
Falso. Ambos tienen una estructura muy sólida y bien organizada, pero Django no respeta totalmente este modelo. Sus creadores dicen que no siguen ningún paradigma en particular, sino su propia visión de lo que sería correcto. Para dejarlo un poco más claro, en este framework el controlador se llama “vista” y la vista, “plantilla”. Por lo tanto, estaríamos ante un MVT (por llamarlo de alguna manera).
RoR, en cambio, sí cumple totalmente esta especificación. Esto no le hace ser mejor, ya que, como hemos dicho, Django tiene un sistema muy parecido. Lo que sí le hace situarse por encima de su competidor es el hecho de que absolutamente todo sea un objeto. Esto consigue que sea un framework 100% OOP.
Django es más rápido
Verdadero. Se han realizado diferentes benchmarks que demuestran este hecho. De todas maneras, la creencia de que Rails no escala cada vez es menos cierta. Con la llegada de la versión 2.0 se mejoró muchísimo su rendimiento, pudiendo impulsarlo aún más si lo ejecutamos sobre un servidor Mongrel.
Como prueba de ello están varias comunidades con gran afluencia de tráfico programadas en RoR, como MTV España, LaCoctelera o Twitter.
Pese a esto, Django le sigue llevando la delantera (sobre todo en peticiones por segundo).
Rails te hace ser más productivo
Verdadero. Es el punto fuerte de RoR. Bueno, mejor dicho: es el punto fuerte de Ruby. Estar apoyado sobre este lenguaje hace que el código sea más limpio y sencillo. Los métodos para hacer tareas más comunes son increíblemente simples, lo que disminuye el tiempo de desarrollo y la posibilidad de error. Ruby está hecho pensando en el programador, y eso se nota.
Django, al ser Python, también disfruta de una buena sintaxis, pero no puede competir con el nivel de abstracción de Ruby al estar bastante más ofuscada.
Django tiene un sistema de URLs más flexible
Verdadero… a medias. Incorpora un sistema de routing muy potente, que consiste en un archivo (urls.py) que relaciona la URL con las funciones que se deben ejecutar (con soporte de expresiones regulares). Como punto negativo, es obligatoria la creación de un método en el modelo por cada dirección.
Por contra, RoR utiliza un redireccionamiento basado en slashes bastante rígido, pero es totalmente configurable si queremos cambiar su formato (el cual es bastante bueno de por sí).
El sistema de plantillas de Rails es muy confuso
Falso… a medias. RoR no soporta la sustitución de variables en los archivos de vista, sino una combinación de Ruby y HTML. Gracias a la simplicidad de este lenguaje, se consigue un código limpio sin tener que pasar por un procesado extra, pero su correcta utilización depende de la habilidad del programador.
Veamos, por ejemplo, la generación de una nube de tags:
Plantilla en Django:
-
<h3>categories</h3>
-
<p class="taglist">
-
{% for tag in tags %}
-
<a class="level_{{ tag.pop_level }}" href="{{tag.get_absolute_url }}">{{ tag.name }}</a>
-
{% endfor %}
-
</p>
Plantilla en RoR:
-
<h3>categories</h3>
-
<p class="taglist">
-
<% @tags.each do |tag| %>
-
<%= link_to tag[:name], tag_url(tag[:name]), :class => "level_#{tag[:pop_level]}" %>
-
<% end %>
-
</p>
Como se puede observar, ambos necesitan 6 líneas que hacen prácticamente lo mismo, por lo que no hay muchas diferencias en este caso. De todas maneras, al menos en Rails, lo mejor es separar la parte que genera la iteración de los tags de la que lo muestra, pero se ha presentado de esta manera para poder comparar mejor los dos ejemplos.
Si aún así necesitamos un sistema de plantillas, el framework simplifica mucho la instalación de uno como Liquid, al que se trataría como a un plugin más.
Los dos soportan AJAX
Falso. Soportarlo, lo soportan, pero RoR es el único que lo tiene integrado de serie. Incorpora los toolkits Prototype y Scriptaculous, haciendo que la implantación de funcionalidades con AJAX sea bastante rápida. Django, por contra, no da ninguna facilidad en este aspecto. Cabe la posibilidad de instalarle algún plugin que lo mejore, pero sigue siendo un proceso demasiado rudimentario.
El código de Django es más ordenado
Verdadero. Al estar escrito en Python, hereda su estilo de programación. Indica las estructuras de control por medio de la indentación, por lo que obliga a los desarrolladores a tener un código mejor estructurado.
Django tiene más extensiones
Falso. Se tiende a afirmar esto por la popularidad de Python. Es verdad que hay más de 10000 librerías para este lenguaje que pueden ser adaptadas para Django, pero de igual manera gran cantidad de ellas para Ruby y, sobre todo, para Rails. En cambio, las desarrolladas específicamente para Django son bastante menos.
RoR tiene más requisitos
Falso. Aunque se recomienda encarecidamente utilizar Mongrel como servidor de Ruby, se soporta también su instalación como módulo de Apache (mod_ruby).
Además, existen ejecutables que nos ayudan a hacer todo el proceso en pocos pasos, tales como RubyStack o InstantRails.
Los dos implementan ActiveRecord
Falso. Rails utiliza este patrón para sus transacciones con la BBDD, pero Django no. Como era de esperar, ya que viene siendo la tónica general de actuación de sus creadores, se ha optado por una solución parecida pero diferente. Requiere escribir bastante más código, lo que lo hace más pesado y propenso a errores.
Pongamos un ejemplo.
Así instanciaríamos una clase de modelo en Django:
-
class ReadingOccasion(models.Model):
-
reader = models.ForeignKey(Reader)
-
book = models.ForeignKey(Book, edit_inline=models.STACKED, num_in_admin=1)
-
finished = models.DateField(core=True)
-
reading_time = models.FloatField(core=True, max_digits=5, decimal_places=2, blank=True)
-
notes = models.TextField(maxlength=2000, blank=True)
Y así en Rails:
-
class Reading < ActiveRecord::Base
-
belongs_to :book
-
belongs_to :reader
-
end
Como se puede ver, no hay color.
Conclusión
Fácil, sencillo, simple, rápido… Esas son algunas de las palabras que es imposible dejar de repetir cuando hablas de Ruby On Rails. Django (y Python en general) apuesta más por alejarse del paternalismo y ver las cosas desde un enfoque más primitivo. RoR, en cambio, nos intenta llevar por el camino más corto.
Al final, como en todo, la decisión es del programador. Pero una cosa está clara: si lo que queremos es pensar más y escribir menos, Rails es lo que estamos buscando.
Interesante, de nuevo, este artículo. Me ha gustado el formato y la redacción, se hace amena.
Hay que decir que los programadores aférrimos de Python, considerarán que el formato de Django es acertado y, que se separe de los métodos estándares como MVC, y otros más, no es más que una genialidad para hacer las cosas "mejor"… eso quizás habría que estudiarlo.
Que Python sea más rápido, supongo que se debe a la implementación de python sobre Apache, y a cómo trata Rails su ejecución particular, puesto que hice pruebas de ejecución de uno y otro (Python y Ruby), y Ruby en sí me daba mejores tiempos. Cuando tenga un rato subiré unas pruebas de ejecución… a ver si puedo hacer lo mismo con la ejecución de programas en Django y Rails :-P
Pues nada, que me enrollo como una persiana… ¡que has hecho un buen trabajo!
Poco después de que comentases he arreglado algunos fallos de redacción, pero gracias.
Y sobre el tema del post:
Como bien dices, habría que estudiar si el modelo que utiliza Django es mejor o peor que otros más extendidos, ya que no me siento capacitado para dar mi opinión sobre ello.
Me gustaría ver una explicación más detallada por parte de sus creadores de porqué no han seguido el tan famoso MVC y, sobre todo, qué tiene su modelo que le hace estar por encima de él (imagino que creerán que lo está, sino no lo habrían utilizado xD)…
Y, bueno, la rapidez… lo he puesto por varias pruebas de rendimiento que he encontrado por la red. Creo recordar que he visto 3, así como varios blogs que comentaban lo mismo (pero puede que hayan hecho como yo: basarse en la experiencia de otros xD). De todas maneras, estaría bien que publicases las tuyas… a ver si las vemos pronto.
En fin, me alegro de que te haya gustado.
¡Saludos!
excelente articulo…muy acertado..la verdad programo en python y ahora estoy aprendiendo ruby, pero si me pones a elegir un framework elijo mil veces rails, es mas sencillo y la sintaxis mas limpia (pese a que django se basa en python que es super claro) si bien tiene problemas de escalabilidad que poco a poco se van disminuyendo, creo que es mas intuitivo y comodo que django, que vale acotar que fue mi primera opcion al ya saber python pero que luego lo abandome
Gracias Jonas, me alegro de que este artículo siga siendo útil, pese a que hace casi un año que lo escribí.
Un saludo.