Ventajas e inconvenientes de Django frente a Pylons

Descargo de responsabilidad: He creado Pylons.

Realmente depende del tipo de aplicación que estés construyendo. Ambos frameworks se crearon originalmente para resolver problemas diferentes. A pesar de lo lejos que han llegado desde su creación, sigue siendo muy útil tener en cuenta los problemas para los que fueron creados porque muchas de esas decisiones han guiado el desarrollo posterior.

Django fue hecho para sitios de periódicos, no sólo para un sitio de periódicos (de publicación), sino para hacer sitios enteros rápidamente. Por lo general, tenían un personal que necesitaba empezar a empujar el contenido en el sistema lo antes posible, incluso antes de que la versión pública del sitio pudiera estar hecha. Esto todavía se refleja claramente en Django, ya que tiene una interfaz de administración muy completa y fácil de usar para que el personal comience a introducir contenido.

Cuando se creó Django, SQLAlchemy no existía y SQLObject era un poco... escaso, así que Django tiene su propio ORM. Sigue siendo deficiente en muchos aspectos comparado con SQLAlchemy, pero funcionará muy bien para las necesidades de mucha gente.

Django también tiene el concepto de "aplicaciones", que son sólo directorios dentro de un proyecto Django que hacen una función específica para el sitio. Esto refleja la necesidad de los creadores originales de compartir rápidamente los componentes de un sitio con otros sitios que hayan hecho. Por ejemplo, añadir rápidamente comentarios, o reseñas, a otro sitio Django.

Aunque puedes utilizar SQLAlchemy, u otros lenguajes de plantillas como Mako, en Django, muchos de los puntos fuertes de Django (las "aplicaciones" existentes que puedes reutilizar, la interfaz de administración, partes de la biblioteca de formularios) se esfuman en cuanto utilizas SQLAlchemy en cambio del ORM de Django.

Al igual que los autores de Django hicieron Django para rascar su picor particular, yo hice Pylons para rascar el mío.

En mi experiencia, la creación de sitios es una parte muy pequeña de su vida. En realidad, paso mucho más tiempo manteniendo una aplicación web, o añadiendo características a una ya existente. Así que la primera cosa que quería en el marco era lugares comunes para poner los "fundamentos" de una aplicación web, de modo que sería más fácil de mantener, y que si otras personas conocían Pylons tendrían un tiempo más fácil de saltar en ayudar a mantener una aplicación Pylons.

Para todos los sitios que he construido, generalmente implican esquemas de bases de datos y back-ends de datos muy diferentes, con poco en común. Así que compartir "aplicaciones" como hace Django no es una prioridad, ni es factible dado lo diferente que será cada aplicación (no puedes compartir partes que requieren un concepto específico de cómo se manejan los usuarios si las diferentes aplicaciones necesito para manejarlos de manera diferente).

También necesitaba algo pequeño, que no intentara dirigir el espectáculo por mí. Quiero ser capaz de entrar y determinar cómo va a responder algo sin esperar que el framework me "deje" hacerlo. Por esta razón, una aplicación Pylons es un poco diferente de la mayoría de los frameworks, en que el proyecto en sí mismo construye el objeto de la aplicación, lo que facilita la entrada y el cambio de cualquier parte del núcleo según sea necesario.

Por lo tanto, la pregunta que debería hacerse alguien que está tratando de elegir, es ¿qué está tratando de construir? Porque esa es realmente la mejor manera de determinar el marco apropiado para la tarea.

Además, por el momento, el libro de Pylons está 100% actualizado con Pylons, mientras que el libro de Django ha sido actualizado para la versión 1.1 de Django.