Runcible Blog

Since Ned put the smack down on the web framework zealots, and Antonio chimed in about the intangible benefits of working with a "fringe" framework/language, I thought I'd add my 2 rupees to the discussion on this whole web-development thang.

Having spent a year working on a Struts application (and evaluating several other Java frameworks) at my last gig, the difference between those platforms and Django (or hey, even Ruby On Rails) means the difference between being able to ship new features and make large changes to the code on a weekly rather than monthly basis. Ever since DHH brought Ruby on Rails down from Mt.Sinai and proclaimed that all of our controllers would go in this directory, and all the views would go in this other directory, plenty of people have woken up to the idea that web frameworks can take advantage of simple structure and use minimal configuration while still being powerful enough to "scale" (in the complexity sense of the word) to large projects.

While I was working on two projects at the Eagle-Tribune – the primary one in Java, and the other Django – I found myself asking, Why do I have to do have to do it this way? on the Struts project, while Django felt much more natural to me. As popular as Struts is, it seemed like an evolutionary dead-end after working with Django. You know your technology stack is doomed when you're afraid to add something new or change anything because it's such a hassle to wade through configuration files -- or, when there's a whole cottage industry around managing those configuration files

Working with Django at Tabblo lets me get on with the business of creating cool stuff without throwing road blocks up every 10 feet, as my Java Struts experience seemed to show. (I'm sure it helps to work with some passionate keen-beans) Also, perhaps ironically, working with a higher-level language leaves more time to spend on optimization because implementing features is comparatively easy. With "Web 1.0" languages/frameworks, (i.e. Java/Struts) you kind of have to think about performance up front and continually. Are you going to decide to use EJB? Any kind of ORM? What implementation of List should you use? ArrayList, Vector, LinkedList? I'm not saying one shouldn't understand the tradeoffs that different approaches entail, but with more agile languages and frameworks, you can defer those performance decisions until later (or never!). Java makes you think about performance optimization whether you need to or not.

Also, as the resident Magic-Remover at Tabblo, I'd like to make a couple observations about our migration to Django's trunk. First, it can be difficult to say what moving a large code base like Tabblo from one framework revision to another will gain -- is there a measurable gain in productivity? performance? features (which could not be backported)? Maybe yes; maybe not. But the overriding feeling was that staying current with Django would buy us some of those intangible benefits that open-source software tends to foster. Looking at some of the active branches in Django's Subversion repository gives a peak at some of the intriguing features that dozens of contributors are working on. So, although the short-term gains are minimal, the long term of Django development looks pretty exciting.

The other point I'd like to make about Django 0.95 is that the developers have moved much closer to the sweet spot of a powerful, easy to use and understand, and flexible abstraction in the new ORM. A simple example is that I built a rudimentary Django-0.91-style wrapper around the magic-removed syntax fairly easily (if only for the purposes of testing). I think it's a good sign that the new ORM is powerful enough to encompass the old ORM, but not the other way around.

Removing the magic out of Django let's us build even better magic into the Tabblo applications. Every decent framework should be pushing towards that goal. The days of bondage and discipline languages and "enterprisey" web frameworks are over. We youngsters with limited attention spans for XML sit-ups are getting stuff done with fewer acronyms and less code.