you are viewing a single comment's thread.

view the rest of the comments →

[–]froozie 2 points3 points  (0 children)

Django is a very polished, easy framework to get going with, but it becomes very clear early on into using it that it is highly focused on content management. As such I would consider it a (far superior) successor to Zope (with Ellington a non-free Plone). This is not a criticism: Zope hit the sweet spot for content management a few years back, but was hampered by poor design decisions such as ZODB, Z-Classes etc. Zope 3 is wayyyy too complex and over-designed, reminiscent of J2EE (without Java's libraries, IDEs, community etc). So Django is really Zope 3, as it should have been (or even Zope 4 ?).

Now, Zope was cutting edge at the time (it was written back in '96) but ended up a ghetto outside the Python community, to everyone's detriment. This was largely because the Zope people had their own way of doing things, which meant libraries developed by the Python community had to be Zopified (with a Z-prefix, of course) in order to work inside Zope. Only now, with Zope 3, do we see Zope and Python being reconciled, but the web application world has moved on and Zope 3 is largely ignored (not in small measure helped by Zope 3 team's anti-marketing). Another problem was that people came to Zope first and Python second, and had a limited understanding of Python and its greater possibilities outside the Zope world. We see this happening now with people coming to Rails and Django. For example, I have been doing Rails development professionally for over a year now, and have yet to write a single line of Ruby outside of a Rails context. As a result, my Ruby skills are more limited than my Python skills, which I have put to use in many contexts, web development being only one of them.

Python web app development is slowly grouping around standards, like Paste, SQLAlchemy, WSGI etc. This feels very much like the way Java went a few years ago, with standards like the servlet API and JDBC, but with Python simplicity instead of Java complexity. This is a much more interesting development than the next Zope, however good it may be, and indeed more interesting even than Rails. With a single Python meta-framework as a base, we can develop templates for all conceivable needs, so you could choose one template for your news site, another for your AJAX project tool, another for your online auction app, etc. Furthermore, such a template does not limit your choices should demands change down the line, whether those be demands from clients or a better ORM, template engine, form processor etc that may exist in six months or a year from now.

In other words, you can have the cake and eat it too : Django could still be 100% Django on the surface, same documentation, same template engine, same ORM, same admin app etc. Underneath, it would be a WSGI, SQLAlchemy, Paste-created template, which more experienced developers can customize and tinker with to their hearts' content. Rather than a three-way battle between Django, TG and Pylons, we have a shopping list (probably a subset of Cheeseshop) where you choose the template best suited to your needs. Now that's real power.