Django vs Rails

El origen

Desde hace ya un par de años me ha interesado mucho el desarrollo web, pues siempre me pareció asombrosa la manera en que pudiéramos acceder a contenido informativo, de entretenimiento, educacional y multimedia a través de una simple página web. Toda esta fascinación comenzó en secundaria, donde me enseñaron conceptos básicos sobre HTML y las hojas de estilos en cascada. Sin duda, me sentía como un artista al crear mis primeros sitios (completamente estáticos por cierto) y darles vida con colores extravagantes y acomodos raros.

Más adelante, me volvió a interesar la manera en que estas páginas web estaban construidas (algo que me parecía mágico a decir verdad). Fue así como me adentré un poco más y conocí una herramienta que llaman de distintas maneras dependiendo del navegador que se use (en mi caso, Inspector). Recuerdo que en una ocasión me dispuse a inspeccionar el HTML de un sitio desarrollado por Google en conjunto con Lego, una gigante de los juguetes. El sitio era https://www.buildwithchrome.com/ y me causó mucha curiosidad el hecho de que tuvieran un dragón en el HTML como forma de advertencia para que habilitaran Javascript en el navegador.

¡Cuidado con el dragón!

Pasaron algunos años más, y al comenzar a estudiar Ingeniería en Sistemas Computacionales, me di cuenta que desarrollar este tipo de páginas web sería un campo en el que podría incursionar. Esto me emocionó de verdad.

Así pasaron un par de proyectos, donde tardaba bastante en acomodar la información, en repetir la misma estructura de página en página que hicieran que el contenido fuera coherente y la navegación fácil. Cabe destacar que este par de sitios no tenían nada de información dinámica (de hecho, no tenía una idea clara sobre qué era información dinámica en aquellos momentos), pues sólo eran sitios a modo de presentación.

Pasó un año y el semestre pasado me tocó enfrentarme junto con mi equipo a la primera aplicación web dinámica. Debido a la complejidad del proyecto, un compañero y amigo que es realmente movido y trabajador, nos recomendó que usáramos un framework de desarrollo web llamado Django. Sin que supiéramos mucho los tres integrantes del equipo, accedimos y yo comencé un camino que sigo recorriendo a la fecha y en el cual he aprendido bastante.

Para no hacer el cuento más largo, como ya dije, este ha sido un camino lleno de frustraciones pero muchos aprendizajes en el desarrollo web, rama de la ingeniería de software que me gusta mucho y en la cual trabajo actualmente.

Los preparativos

Así pues, por fin he llegado a donde quería, de aquí en adelante les presentaré mi experiencia con los frameworks de desarrollo web, desde qué son, qué hacen, en qué nos ayudan y una breve comparación con los dos frameworks con los que he trabajado hasta la fecha, Django y Ruby on Rails.

Framework en español quiere decir marco de referencia, así pues, un framework de desarrollo web es un marco de referencia que nos ayuda a hacer aplicaciones web de manera más rápida y organizada, esto con una colección de herramientas que facilitan el desarrollo y codificación de un proyecto web.

Muchos de los frameworks logran su objetivo al implementar un patrón de arquitectura de software llamado MVC, modelo-vista-controlador. Con este patrón de diseño, cada elemento tiene su objetivo propio.

  • M: El modelo se encarga de representar la información que será utilizada en la aplicación.
  • V: La vista se encarga de especificar cómo será presentada la información que se obtenga del modelo.
  • C: El controlador se encarga de responder a eventos, en este caso los métodos del protocolo HTTP, y se encarga de especificar qué datos serán los presentados.

Cuando comencé con Django, este patrón de arquitectura de software aún no me hacía mucho sentido, sin embargo fui entendiendo mucho más a través del desarrollo de mi primera aplicación en Django y lo entendí completamente al realizar un tutorial para Ruby on Rails.

La batalla comienza

Sin más rodeos, lo más conveniente será presentar las diferencias que he visto entre estos dos frameworks y una comparativa entre ambos. Es importante aclarar que me centraré más que nada en mi experiencia, puesto que comparativas ya hay, como una muy completa que leí en el siguiente enlace: https://bernardopires.com/2014/03/rails-vs-django-an-in-depth-technical-comparison/

Django es especial para mí, pues fue el primer framework que aprendí (aunque no lo conozco completamente), y más porque está escrito en el primer lenguaje de programación que aprendí: Python. Gracias a estar escrito en Python, Django es muy explícito a lo largo y ancho de todo el código (si se tienen buenas prácticas, claro está).

Por otro lado, Rails fue un poco difícil al principio, puesto que cuentan con una sintaxis un tanto extraña para los que apenas comienzan con un lenguaje como Ruby. A pesar de esto, Ruby on Rails demostró ser entendible después de haber hecho un tutorial muy útil como el que hice (Ruby on Rails Tutorial, disponible en: https://www.railstutorial.org/book). Gracias a la facilidad de comprensión de Python (leyendo el código de mis compañeros fue como entendí muchas de las cosas que antes no), Django tiene un punto a su favor.

Arranques de obsesivo-compulsivo

Otro apartado que me gustaría mencionar es la manera en que generan aplicaciones con estos frameworks y la estructura por defecto que tienen al ser creadas.

En el caso de Django, cuenta con una estructura de directorios muy sencilla, donde se pueden apreciar menos de una decena de archivos creados por defecto; este comportamiento da al desarrollador flexibilidad y le permite crear su proyecto como a éste le convenga.

Por otra parte, Ruby on Rails cuenta con una cantidad significativa, en comparación, de directorios; cada uno con su propósito específico. En un principio, esto podría resultar un tanto caótico y confuso, pero puedo asegurarles que mantiene todo en orden y para alguien que es un apasionado por el orden, este es un gran punto a favor de Rails.

Ruteame esta

El tercer apartado que quiero tocar son los URL’s. Estos son los encargados de poder brindar una navegación exitosa a través de nuestra aplicación.

Para esto, Django cuenta con un archivo específico llamado “urls.py”, donde se declaran todas las rutas que integrarán la aplicación. En este caso, cada ruta debe de ser especificada, y el uso de expresiones regulares es necesario para poder exprimirles todo el jugo.

En el otro lado del ring, Rails cuenta con un archivo llamado “routes.rb” y al igual que Django, aquí se declaran las rutas que integrarán la aplicación. La gran diferencia reside en que desde un inicio, Rails hace fuerte hincapié en el uso del estilo de arquitectura REST, por lo que este framework cuenta con una serie de trucos bajo la manga, y con el simple hecho de declarar distintos recursos, los URL’s de éstos estarán disponibles. Así pues, en este apartado, el punto es a favor de Rails.

Prueba y error

El desarrollo basado en pruebas es algo que está en boga entre los desarrolladores. Esta forma de desarrollar se enfoca en primero ver las maneras en que pueda fallar nuestra aplicación y cómo es que podríamos meter la pata, para después crear una serie de pruebas que se encarguen de avisarnos cuando es que nuestra aplicación falle, consecuencia de nuestras metidas de pata.

En cuanto a herramientas de prueba, tengo mucho más experiencia en Ruby. No obstante, realicé una investigación que me hizo darme cuenta que Django cuenta con un robusto sistema de testeo agregado, casi tan bueno como el de Rails. El detalle estaría en que por default, al hacer migraciones en Rails, se agregan archivos de pruebas para los modelos, controladores y vistas, algo que en Django no pude encontrar tan accesible (tal vez sea mi falta de experiencia en testeo en Django). Preferiré no dar puntos en este apartado, pero me inclino más a Rails.

Recursos renovables

Algo que es indispensable en cualquier aplicación web y sería descabellado pasar por alto son los recursos estáticos necesarios para nuestro proyecto, más en específico quiero hablar de los CSS’s y JS’s que son necesarios para tener una buena experiencia de usuario.

En Django, los recursos son declarados individualmente en cada vista y sólo en algunos casos pueden ser implementados en todas las vistas en general.

Por su parte, Rails cuenta con un precompilador de estos archivos, que optimizan y comprimen los recursos para que sea más rápido cargarlos a través de cada petición. El problema está en que he tenido complicaciones para poder designar un solo recurso a una vista en específico de manera correcta y limpia. Posiblemente sea porque aún me hace falta experiencia en este ámbito, pero por lo pronto Django se lleva el punto en este apartado.

Documentos, documentos

Por último, quisiera exponer la experiencia que tuve con la documentación oficial y comunidad que apoya cada uno de los frameworks.

Rails cuenta con una documentación amplia, sin embargo, creo que la información podría tener una mejor presentación y ordenamiento, pues resulta un poco difícil encontrar los apartados que nos pudieran sacar de dudas. A pesar de ello, Ruby on Rails cuenta con una gran comunidad de desarrolladores y será muy difícil no encontrar una solución en sitios como StackOverflow a cualquier obstáculo que tengamos al desarrollar nuestra aplicación.

Por otro lado, la documentación de Django es mucho más pulcra y ordenada en mi opinión, y así como Rails, también cuenta con una comunidad importante de desarrolladores (no más grande que Rails) que podrán apoyarnos cuando tengamos complicaciones. En este caso, Django se lleva el punto.

Conclusiones inconclusas

Para concluir, se habrán dado cuenta de que se llegó a un empate en puntos. Sin embargo, creo que es importante mencionar que la evaluación aquí presentada no es del todo objetiva y cuenta con una experiencia previa que me hizo llegar a tales conclusiones. Sonará trillado, pero al final, creo que la elección de un framework deberá de ser tomada considerando las necesidades del proyecto a desarrollar, así como la experiencia previa del programador(es) con el framework “x” o el framework “y”, así como la preferencia de ser explícitos en el caso de Django, o la preferencia de convención sobre configuración en el caso de Ruby on Rails.

En cualquiera de los casos, creo que los frameworks de desarrollo web están aquí para quedarse, y son herramientas que nos ahorran a los desarrolladores web bastantes dolores de cabeza y que al final nos dejan enfocarnos en lo importante de una aplicación: la propuesta de valor, diseño y presentación que harán que nuestra aplicación se distinga de las demás.

“Keep calm and code on.”