Django vs Tapestry

January 19, 2010

I been doing Tapestry since early Tapestry 4. I've written a call centre front end to a large loan application with it (team of four), and I've used Tapestry 5 in conjunction with spring, hibernate and Postgres to build a small case tool type application for storing our web service definitions in. We generate code from this.

I have developed several project using Django and Python. I'm using Tapestry 5.0.10ish with the case tool thing, so some of the issues below might have been addressed in later versions. Also be aware that due to our development techniques (which I wrote, oops, before we started using Tapestry), I can't use the auto page reloading stuff, so I have to use ant to rebuild the war every time I make a code change.

Some of my issues in Tapestry:

  • HTML is not pretty. If you do a view source on a Tapestry page, the html is all on just a few lines, and it's difficult to see what's going on. Django makes this easier to read and there's less unexpected auto-generated stuff in there.

  • The url changing that makes site/showsite url in tapestry turn into a reference to site/show. This catches me every time and really annoys me.

  • The large ecosystem of projects. I need Spring. I need Hibernate. I need all the supporting jars and the war file that results is huge. Django has most of this built in, so there isn't as much to learn from different books. Tapestry feels big and complicated. Django feels simple, but beneath that simplicity is a lot of very powerful things that you can ignore until you need them. There's also lots of little projects out there you can plug in (or just copy source).

Things that are better (for me) in django:

  • class reloading. I can start up a Django server to test with by running ./ runserver. This automatically supports reloading when I save changes to my source. Admittedly Tapestry can do this, but I've never been able to get it working given our source code structure limitations. I also can't use Maven, so had to manually find the supplier jars needed when I set the project up. This is difficult.

  • ORM. Rather than writing a Spring service (with interface) which calls another Spring service (with interface) to do database access, I can use the built in ORM to do the simple things, and fall back on SQL for the more complex.

Here's a select for all blog entries in the Django category

BlogEntries = BlogEntry.objects.filter(category='Django')

Here's the same select, but only showing the first four rows:

BlogEntries = BlogEntry.objects.filter(category='Django')[:4]
  • Templating system. Tapestry has XHTML templates, Django has pure text templates. Very easy to use for emails and non-html resources. I found a Django plugin (<100 lines of code) that would store templates in the database rather than as part of the source. This means that you can have some dynamic templates (different ones for different customers, same codebase) really easily.

  • JavaScript. There's very little JavaScript in the stuff Django does. This makes it really easy to add jQuery things and follow tutorials on the web. Django doesn't get in the way. It's difficult to see what's going on when doing JavaScript with Tapestry, through that's probably down to the view source issues. Tapestry does however include a non-jQuery library by default.

  • Urls. I never found a way to pass more than one parameter on the URL to a page in Tapestry. I think there was a way but it was quite complicated and involved writing a lot of code.

URLs in django are regular expressions, so this:

(r'^contests/(\d+)/$', 'Site.contests.views.single_contest'),

means that whenever the /contests/123/ url is called, the single_contest function is called passing in a value of 123 as the first parameter. You can put multiple things in brackets, and have the values passed through. Simple and very powerful.

  • Admin site. Django has an awesome auto generated site for maintaining the data for your site. It's all you need if your site is mostly display only, you write the display views and use the admin site for changing data.

What Django can't do easily

  • Components. I miss being able to embed a component with functionality on a page.

  • N Tier. Django is a web app straight onto the database. Most of the sites developed for large financial customers will be 3 tier (Web, App, Database) and so will need to have web services between the Web and App tiers. This would be do-able with Django by writing more python, but you'd lose a lot of the advantages it offers (particularly the Admin).

  • Database Integration. Django currently only supports one database at a time for a site (Update: code for multiple databases is now in the repository). It also doesn't do any connection pooling out of the box.


For me, Django is much more suitable than Tapestry for single tier web apps. It's quick to develop in and the code produced is very maintainable (there isn't very much of it!). For anyone developing multi-tier solutions, in a large corporate environment, I'd be inclined to go with a Java based solution, like Tapestry. Large corporate customers like and expect war files (yeah, I could do Django/Jython but that just smells a bit) and know how to look after them. However, if you're developing an in house app (where you control deployment), Django does give a very quick option for front end development.