Django vs Pylons
Son dos de los frameworks de desarrollo que se disputan, junto con RoR y TurboGears, la medalla de oro en plataformas productivisimas de generación de aplicaciones webs. En este post comparo ambas herramientas según diversos factores.
Nota: para haceros vuestra opinión personal, en cada caso intentar pensar ante todo en la productividad y simplicidad de las herramientas. De hecho la simplicidad implica legibilidad que a su vez proporciona mayor mantenibilidad y con ello más productividad
MODELO DE DATOS
Pylons sigue la linea de RoR de crear las tablas en SQL e instrospeccionar después el modelo. No resulta en mi parecer demasiado elegante ni limpio, entre otras cosas me gusta la idea de tener un models.py donde mirar los campos sin tener que hacer un describe table o un \dt (que te da el modelo a más bajo nivel, a nivel SQL)
Lo mejor es creación automática del modelo y que el programador no huela el SQL (p.ej. en django con su syncdb). Para mi la filosofia Django aquí es mucho mejor.
Otro pero muy importante, para los clientes que lo requisitan, es que Pylons no soporta Oracle (SQLObject no lo soporta) y Django si.
PLANTILLAS
Para un mejor estudio de las plantillas, me he ido a un ejemplo concreto. Tanto django como pylons tienen en sus tracs respectivo el propio código de su página web (http://www.djangoproject.com/ y http://pylonshq.com/ ). Pues bien, he ido a comparar las plantillas de sus respectivos páginas de portada.
- Esta es la de django:
http://code.djangoproject.org/browser/djangoproject.com/django_website/templates/base.html
- Esta es la de pylons:
http://pylonshq.com/project/pylonshq/browser/pylonshq/trunk/pylonshq/templates/index.myt
Fijaros como myghty mezcla python a pelo en las plantillas. Django no lo permite. Volvemos un poco a las ZPT, es decir, a incluir demasiada lógica a las plantillas. Django por filosofía quita potencia a sus plantillas para que se encarguen solo de visualizar. Por ejemplo, en pylons puedes hacer un SELECT en la base de datos en medio de la plantilla. Por ejemplo:
<br />
% user = c.model.User.mapper.select_by(uid=item.user)[0]
<span class="date"><% str(item.posted)[:10] %> - <% user.firstname %> <% user.surname %></span>
Otro ejemplo de muestra de complejidad de myghty es la herencia de plantillas. Os pongo el mismo ejemplo en django y en myghty:
- Plantilla heredada (index.myt)
<%flags>inherit='/base.myt'</%flags>
Contenido principal
- Plantilla base (base.myt):
<html>
<body>
<h1>Mi primera web</h1>
% m.call_next()
</body>
</html>
- Resultado:
<html>
<body>
<h1>Mi primera web</h1>
Contenido principal
</body>
</html>
</body>
</html>
Ahora en django.
- Plantilla heredada (index.html).
{% extends 'base.html' %}
{% block content %}
Contenido principal
{% endblock %}
- Plantilla base (base.html)
<html>
<body>
<h1>Mi primera web</h1>
{% block content %}
{% endblock %}
</body>
</html>
</body>
</html>
¿Qué os parece más legible? A mi sin duda la de django.
De todas formas, el sistema myghty esta bastante bien y además Routes supone una gran ventaja aquí sobre django.
URLS
Lo de Routes está muy bien teóricamente, y si se desarrolla bien usando Routes nos podemos quitar los problemas en la definición de URLs y asegurarnos que siempre vayan a su destino aunque se cambie el árbol de navegación. pero no se si en la práctica lo que hace es dar mayor complejidad a las plantillas, y hacerlas mucho menos legibles.
Os pongo un ejemplo de perdida de legibilidad en la siguiente forma de definir un formulario:
<% h.form_remote_tag(url=h.url(action="search"),
update="photos",
loaded=h.update_element_function("spinner", content="")) %>
<fieldset>
<label for="tags">Tags:</label>
<% h.text_field("tags") %>
<% h.submit("Find") %>
</fieldset>
<% h.end_form() %>
Efectivamente los enlaces no se van a perder con Routes, pero… ¿no es más complejo de comprender? ¿que pasa si le damos esto a un diseñador?
SERVICIOS Y FUNCIONALIDADES
Vemos algunas funcionalidades avanzadas ofrecidas por Django y el estado de las mismas en Pylons (corregirme si alguna es falsa):
Interfaz de administracion automática
No existe en Pylons y en Django si.
Vistas genéricas
No hay en pylons que yo sepa y en Django si
Configuración del proyecto
Si comparo las multitud de opciones de configuración de Django con las opciones de pylons, se observa que Django ofrece mucha más potencia.
Constructor de formularios con widgets y validación
En pylons existe FormBuild pero no está finalizado… nada más hay que mirar su documentacion de ejemplos. En django tenemos esta maravilla.
Seguridad
Django viene con su sistema propio de usuarios y grupos y de control de acceso a recursos. En pylons, parece que debes construirtelo tu siempre, tal y como se indica aqui y aqui (por cierto, ¿pq no está esta doc en la web?).
Casi todas las aplicaciones web medio dinámicas van a tener que necesitar un control de accesos por usuarios, grupos y permisos para cada objeto. Django lo trae de fábrica. Es
MUCHO trabajo el que te quita.
RENDIMIENTO Y ESCALABILIDAD
Aquí no puedo decir mucho de Pylons. Se que ambos pueden usar Apache directamente (con FCGI o mod_python) con lo que la velocidad queda garantizada. Si que es cierto que el sistema de caché de Django parece no tener igual en Pylons, pero como usa Paste como servidor, ya me pierdo si éste se encarga de dar rendimiento mediante caché.
En escalabilidad no se que decir. Si puedo decir que en bases de datos (posiblemente el posible cuello de botella) Pylons se basa en SQLObject y no existe implementación bajo Oracle (aunque van a pasar a SQLAlchemy). Django si tiene soporte Oracle.
DOCUMENTACION
Siempre he dicho que Django viene con documentación no muy extensa pero si muy precisa y siempre sobre lo que interesa. Pylons tiene una documentación menos rica bajo mi parecer. Por ejemplo,
- ¿donde está la documentación sobre la API de persistencia? en SQLAlchemy
- ¿donde está la documentacion de las distintas opciones de administración? No existe que yo sepa algo como esta página de Django.
- ¿existe en pylons un tutorial tan descriptivo como en Django? véase esta pagina como ejemplo de documentación cuasi perfecta para aprender.
COHESION
Django es un proyecto completo, y pylons es un conglomerado de productos. Esto, por definición, implica que la cohesion es muy superior. Lo vemos en:
- su sistema de instalacion y configuracion (o sea, su manage.py)
- su integración de componentes (mismo estilo de codificacion, misma orientacion, etc.)
- su filosofía que se mantiene en todos sus componentes (pylons puede tener una filosofía parecida pero no será la exactamente la misma en todos sus productos)
La cohesion, en vista a la productividad, es buena por varios motivos:
- te evitas fallos de dependencias entre módulos distintos (aunque los python Eggs te facilitan el tema, si quieres ir contra el SVN ya es más chungo, por cierto que no veo bundles en pylons como los de Plone, para evitar la desincronizacion)
- facilita la instalación (svn co + enlace y punto). Si quieres ir tirando del SVN (como nos gusta) en pylons, la instalación se puede volver muy costosa.
- te evitas el tener que escribir más líneas de código para hacer “puentes” entre componentes no demasiado cohesionados.
OTROS SINTOMAS QUE INDICAN MAS O MENOS MADUREZ
Aquí otra lanza a favor de Django… ejemplos de que Django es más maduro:
- Tiempo en producción.
- Fijaros en el numero de tickets en el TRAC. Django tiene milestones definidos, versiones, etc. y multitud de tickets. Pylons parece que ni tiene definido un sistema de ticketing con rodaje suficiente (¿solo 8 tickets activos? no me lo creo). Fijaros por ejemplo en este ticket:
Ni más ni menos que no funciona el controlador principal en determinadas opciones.
- Código fuente. Para mi es IMPORTANTISIMO ver las entrañas (los fuentes) para decir observar muchas cosas de una aplicación. Si miramos simplemente la distribucion de directorios de django y comparamos con los de pylons, y sin entrar en detalles (aunque yo si he mirado alguno), podemos observar que:
- django parece mucho más completo que pylons (y no con ello lo veo más dificil de aprender, sino al contrario)
- django ofrece más funcionalidades (ver directorio contrib por ejemplo). Eso sí, como pylons es un conglomerado de proyectos tambien habría que mirarlos (SQLObject, Paste, etc.)
NOTA FINAL
No se si estáis de acuerdo conmigo. Posiblemente sea demasiado taliban por Django, pero no me faltan razones, ya que he realizado ya algún que otro proyecto y estoy francamente sorprendido. Ahora un último ejercicio mental:
Repasar cada apartado anterior y imaginar que tenemos un proyecto semi-complejo entre manos. Ver las implicaciones en materia de productividad en el uso de una tecnología u otra en cada apartado, y seguro que se os aclaran aun más las cosas.
21 dUTC Julio dUTC 2006 a las 4:23
I believe more than a few remarks here are way off. Unfortunately, the Spanish to English translator isn’t too hot.
First, the Myghty inheritance scheme is actually simpler than Django’s. There’s automatic inheritance which means you don’t need the bit at all, and template inheritance gives you powerful abilities to update elements up and down the template wrapping.
Your example is also very misleading because you drop in database selects into a template…. why would you do that??? Just because you aren’t stuck in a straight-jacket forcing you to keep database stuff out of your template, doesn’t make something bad. Myghty just assumes the developer is intelligent enough to know what is and isn’t a good idea.
Second, Pylons comes with no database ORM. You can use SQLObject and write your database code just like in Django, in fact, Django has updated their ORM so that it looks even more similar to SQLObject.
If you want powerful SQL abilities, we suggest using SQLAlchemy. It’s very powerful, and can connect to Oracle, MS SQL, and more. Not only that, but it can do eager loading of data, and run circles around Django’s ORM when it comes to capabilities.
For form validation, we suggest FormEncode. FormBuild is still being worked on, but I generally like making form elements myself, or with the helpers in WebHelpers (which you failed to mention, along with the AJAX abilities provided). Pylons SVN also comes wiht a @validate decorator which makes validating forms really easy.
There’s many more inaccuracies listed here regarding Pylons, these are just the obvious ones that stand out which I was able to translate best.
Cheers,
Ben
21 dUTC Julio dUTC 2006 a las 8:21
Voy a traducir el comentario de Ben al español, que tiene chicha.
Ben, I’m translating your substantial comment to Spanish.
===
Creo que más de unos cuantos comentarios aquí andan desencaminados. Desafortunadamente, el traductor de español a inglés no es muy bueno.
Primero, el esquema de herencia de Myghty es en realidad más sencillo que el de Django. Hay herencia automática, lo que significa que no necesitas poner ese trocito en absoluto, y la herencia de plantillas te proporciona la poderosa capacidad de actualizar los elementos en las plantillas de envoltorio.
Además tu ejemplo es muy engañoso, porque estás poniendo selects a una base de datos en una plantilla… ¿¿¿por qué querrías hacer eso??? Sólo porque no estés encerrado en una camisa de fuerza para mantener fuera de las plantillas los temas de la base de datos no significa que se algo malo. Myghty simplemente supone que el desarrollador es lo bastante inteligente para saber lo que es una buena y una mala idea.
Segundo, Pylons no trae ORM de bases de datos. Puedes usar SQLObject y escribir el código de la base de datos igual que en Django; de hecho, Django ha actualizado su ORM para que se parezca más todavía a SQLObject.
Si quieres tener capacidades SQL potentes, sugerimos usar SQLAlchemy. Es muy potente y se puede conectar con Oracle, MS SQL y más. No sólo eso, también puede hacer carga activa (eager loading) de datos, y le da varias vueltas al ORM de Django en cuanto a capacidades.
Para la validación de formularios sugerimos FormEncode. FormBuild todavía está en desarrollo, pero en general me gusta hacer los elementos de formularo por mi cuenta, o con las herramientas auxiliares de WebHelpers (que evitaste mencionar, junto con las características de AJAX). El SVN de Pylons también incluye un decorador @validate que facilita mucho la validación de formularios.
Hay muchas más inexactitudes aquí con respecto a Pylons; estas sólo son las obvias que destacan y que mejor conseguí traducir.
Saludos,
Ben
===
21 dUTC Julio dUTC 2006 a las 18:46
Hi Ben, before all I’d like to explain Pylons seems to be a fantastic framework. Congratulations.
Ok, it’s a fact that i don’t know Pylons as well as Django, but any case i’d like to anwser you in several points:
- I have used ZPT (and also kid) templates for three years (in fact I continue with ZPT with Plone). I have to acknowledge that mix logic and presentation can be useful for rapid deployment, but not for maintenance and legibility.
- My above code of mixture logic and presentation is in index.myt of pylonshq.com… It’s true that you can separate logic on controller, but at the end you take easy way (of mixing).
- FormEncode it’s ok but, if I don’t miss, You cannot build a form based on widgets of you model automatically. But sorry for do not talk about FormEncode (I forgot it).
- The cohesion is very important. You said that Pylons doesnt require SQLObject or SQLAlchemy or AuthKit or … This can produce a worse cohesion than Django.
- SQLAlchemy can have several times more capabilities, but in my case I have no oportunity for using that. I consider Django ORM very powerful and I don’t need (for now) features like mappers. I’d like simplicity and medium capabilities over complexity and strong capabilities. For that, I prefer Django to Zope 3.
In general, I think with Django I can get productive several times that with Turbo Gears (an example in a real project). Pylons is newer and I didn’t have oportunity for using in a real project.
21 dUTC Julio dUTC 2006 a las 19:19
I agree, mixing logic in the templates is almost always a bad idea, unless the logic is controlling how data is viewed. In the template you cite, the logic is not controlling data, but is actually retrieving data. This is a bad practice, and one I don’t follow, the code you see there is being fixed such that this doesn’t occur.
You’re right that FormEncode doesn’t generate forms. Neither does Django, though its manipulators can make the fields you’re still left laying out the form and the labels. It’s really quick to make those form widgets with the helper functions in WebHelpers though.
Cohesion is definitely important, I think Pylons excels in this aspect since it makes it very easy to use separate tools very easily. If you look at the large batch of import statements that can accrue in Django views, vs the basic one in a Pylons controller, as well as the fact that you can just use your session, or the request from anywhere; you could even consider Pylons more cohesive.
The most important thing I think, is that Pylons doesn’t overlap that much with Django when it comes to its intended audience. Django was derived from a project that was created to meet the needs of the newsroom. Many Django advantages are lost when you’re not using it in a staff content-driven manner, though it should be noted that a huge amount of the webapps people develop are content-driven by a group/staff.
This focus is clearly shown in the layout of a Django project and Apps, merely by how few files it creates for you. Pylons is geared more towards people that want maximum flexibility and customization.
Pretty much everything in Pylons can be customized, and therefore a lot of the configuration is also present in the project directory created for you. There’s a large batch of template languages supported, multiple ORM’s with ease, powerful caching of templates in any template language, easy re-use of WSGI apps and middleware, etc.
If you’re looking for a framework in the future, and your site deviates highly from the workflow that Django is optimized from, give Pylons a try. The new 0.9 which is almost out makes it even easier to use, and I think you’ll hard-pressed to find so many internals documented as highly: http://pylonshq.com/docs/0.9/module-index.html
Cheers,
Ben
21 dUTC Julio dUTC 2006 a las 20:11
I dont think Django is for content-driven apps. You dont have to use admin interface and also you dont have to use a Database, neither any auth system, etc.
By the way, 99% of web apps are using any kind of data model, and normally content is managed by users. Only I see an scenario which Pylons wins over Django: in adding a web interface to non-webs applications that uses SQLObject, etc. or re-use these modules on an existing web. In general, Pylons offers users more posibilities in each component, and Django offers a more homogeneous components and philosiphy.
Django offers you any functionality you said for Pylons, and more:
- generic views
- automatic admin site
- templatetags (for building web components)
- widget machinery (for example there are tutorial for integrating RichTextFields with TinyMCE)
Automatic admin can be used like model of good web with a good CSS and usability. I used, in two projects, admin site for building entire web (for intranet), and looks incredible (and very very fast).
And in develop environment, provides an excelent productivity, for autoreload, precise error pages, excellent debug, etc. (Pylons maybe has good one).
Regards,
Lin
21 dUTC Julio dUTC 2006 a las 21:05
Hmm, it seems you’re still missing some of the great features that have attracted others to Pylons. One of the nice things about excellent WSGI re-use is that we were the first to integrate Paste’s interactive debugger. You get a full-blown interactive AJAX debugger which lets you execute Python statements to explore the traceback (TurboGears is integrating it as well).
We’ve also had functional testing with the ability to introspect and verify all the template renders and session data that was done during the request. Django is just now adding this functionality.
Templatetags aren’t needed when you have the full power of Python behind you. Why learn a new language of template tags to do what you already know how to do in Python? In Django’s case it was because they were purposely limiting access to Python from the web designer. When you have Python available, if you need more functions… import them! It’s all just Python.
Many of these features don’t come from Pylons itself, but other excellent packages. This re-use means you get lots of powerful features that can be upgraded independently of Pylons. The WSGI spec and use within Pylons also means we can keep backwards compatibility much longer, and with less breakage in between releases.
For another example of re-use, consider this recent article covering implementing the Atom protocol in WSGI:
http://www.xml.com/pub/a/2006/07/19/implementing-atom-publishing-protocol-python-wsgi.html
You can copy the WSGI app shown there, as is, into a Pylons controller file, and its ready to go.
Consider that if you have a highly dynamic site that can’t be heavily cached, and you’re doing a ton with the database, the Django ORM’s limitations will quickly beat you. The lack of efficient eager loading, and other advanced database features such as an Identity Map to easily track updated objects will eventually force you to switch to something else. And once you switch, you lose generic views, automatic admin, and widget machinery; since they all rely on you using Django’s ORM.
That kind of situation doesn’t really happen with any of the high traffic sites I’ve seen that are Django powered. Since the content doesn’t change often, caching can be used aggressively to compensate for any possible ORM inefficiencies. This is what I mean when I say that Django is optimized for certain styles of web development. You could use Django for anything obviously, but you quickly lose its biggest selling points.
19 dUTC Enero dUTC 2008 a las 20:47
boys jerking off high school boys porn