Update: I revisited this Grails vs Django discussion in Jan 2015.

Before I met Grails I had spent several years writing my web applications in Perl, including work on two different in-house frameworks to try to make life easier! I also dabbled a little with Ruby on Rails but for some reason it just didn't stick (I think I prefer brackets to words!). Then I discovered Grails (on version 0.3 at the time I think) and the increase in brackets and reduction in semi-colons, thanks to Groovy, fitted me well.

So in the years since then I have written several sites using the Grails framework.

Then in a recent discussion with my SEOSS business partner, Tim put forward the idea of using Django on a project we were quoting for. It's been a while since I last wrote any Python code and I've never used Django before. So I ended up doing some research and put together the following report.

There is a conclusion near the bottom if you feel it's just too long. TL; DR - scroll to the end!

Development Ease

Feature wise I think they are very evenly matched for development. Compared to Java, Grails adds a fantastic automatic reloading of changed classes and components. However I'm not comparing it to Java at the moment and from years of use I also know that the Grails re-loading has it's rough edges and when you do need a full restart, it's slow, very slow. Similarly test runs can suffer from the same extra startup time baggage, eating precious time and concentration.

In contrast Django has almost instant startup time and also includes auto reloading of changes.

Text editor/IDE support, debugging, logging and anything else I can think of they seem pretty evenly matched on, so this one is close but is a win for Django.

Technical Features

The two frameworks take quite different approaches to many things, and name almost everything slightly differently (just to make comparison that little bit easier!) but in one way or another they both seem to cover most of the standard stuff that I'd expect in such a framework. My investigations so far have picked up a couple of differences I want to highlight though.

Admin Pages

Django provides a very nice looking facility to quickly and easily auto-build admin pages that are pre-styled and of production quality. I suspect the limitation is when you find a little extra logic is required in such a page and that isn't allowed for in the auto-built pages, but for many cases this looks really good. The big question is how fast a project would outgrow these pages, or perhaps whether they are actually suitable at all. Most sites will need at least a limited admin system of this type but for most of our projects the vast majority of the development isn't in the admin system anyway.

Static Resources

Both frameworks do cover collection, grouping and publishing of these files (CSS, Javascript, images) but Grails includes versioning (a hash of content) of the file names so that they can be served as cache-for-ever. Django does not appear to include this, although after much searching I think I've found a plugin that does.

Pre-processing to cover things like LESS or optimisation of CSS and JS also seem to only be in hard to find and slightly unclear plugins for Django. The Grails implementations of these are from the excellent resources family of plugins, the base of which now comes installed by default in new projects.

Conclusion (Technical Features)

While I really like the idea of the admin pages, I think they would probably be outgrown quite fast in most cases and I can't imagine living without the resources plugins so I think it's a win for Grails.

Testing

Heavy testing is strongly encouraged by both frameworks. Grails comes with JUnit and also supports Spock relatively smoothly via a plugin. The default testing system for Django appears to be universally recommended for immediate replacement with another Python testing library, but the process seems easy.

Overall both platforms seem to have good support for unit, integration and functional tests. I know from experience there are some edge cases around GORM support in unit tests that can be frustrating but without experience I don't know how Django fairs for this.

I really like Spock tests so that's a definitely positive for Grails but on the surface Django seems to support everything needed for good, quick test development so I think it would be unfair to mark it down. I'm going to call this one a draw.

Libraries

Django has more plugins listed (although I still couldn't find any covering some things I searched for) but Grails can fall back on the enormous base of Java libraries which can be easily included from Maven repositories or manually as jar files.

In practice Django and Python probably have everything needed for most projects but just for the huge number of Java libraries and their very easy inclusion, this has to be a win for Grails.

Developers

This category is to consider the availability of future developers for work we create and for us hiring in assistance on larger projects.

The Django community is definitely larger than Grails, but the Java community is in turn much, much larger than Python. Grails itself is far from small these days with numerous very large companies using it and with many developers available. In my role at SupaJam I have hired permanent Grails developers a few times and always had plenty of applicants. The Brighton Java group even ran a recent event on Grails (unfortunately I couldn't go as it clashed with parents evening).

I don't think there is much difference in the permanent job market but for freelance or contract it may be the case that Grails developers cost a bit more than Django ones, although not by a huge amount.

I'm going to call this one another draw.

Deployment

I think this is the most complex category as production deployments vary a lot anyway. Taking just a simple deployment the two platforms are still very different in many ways. I both love and hate Grails (Java) deployments so I've got some specific points that I want to compare them on. I have tried to list the positives for each (obviously each one is inherently a negative for the other framework).

For Django

• Much smaller memory footprint
• Less moving parts. Typically just Apache or Nginx with a module, rather than a separate service. Although larger deployments would probably run a separate daemon and of course load balancing would effectively force a separate service anyway.
• Much faster restart to pick up changes (ie Apache restart vs Tomcat restart)
• Due to faster restart, less release down time and/or easier release process scripting (especially in clusters with load balancers)

For Grails

• Very easy deployment packaging (ie a WAR file)
• Better support for starting new threads and background tasks
• Built-in (ie managed within application code base) background/cron tasks
• In-JVM state and caching - faster and simpler, eg avoids the need to run memcached

Conclusion (Deployment)

I think this is my toughest call in all of the categories as I really like the simplicity of WAR files, in-JVM state and in-code-base crons. However the large and slow deployment process is probably the thing I like least about Grails. Overall I'm going to call this one in favour of Django.

Experience

This is obviously a win for Grails. The question here is more about how much this is worth. It is very easy to find reports online for both Grails and Django bugs causing people pain and certainly from personal experience I know framework bugs can be expensive when hit for the first time. Beyond that there will always be learning time required for any new framework, especially one with some radically different approaches.

Final Conclusion

The results are:

• Development Ease: Django
• Technical Features: Grails
• Testing: draw
• Libraries: Grails
• Developers: draw
• Deployment: Django
• Experience: Grails

Which makes the final scores (excluding the draws): Django 2 and Grails 3.

Django won for development ease and deployment which are both very important categories, although they were only slim wins. Two of the Grails wins were also quite slim and the third was experience which will dissipate over time. So overall I think they are very closely matched.

For SEOSS the decision was clear. There is nothing in Django that would be expected to counter the huge benefit of our existing experience, at least in the short term. The only option we could sensibly quote on was Grails.

It is worth noting that all of the Django information presented here is from reading things online (the documentation, tutorials, plugin searches and more documentation) and creating a one-line hello world app. So it's probably missing important details, both for and against the use of Django, that can only be found by using it in anger. My aim was to make a decision for a quote we were preparing, not to settle any wars or make life long choices.

Where would the fun be in technology if there weren't always new things to learn. This report may have provided a win for Grails, but it has also piqued my interest in Django. As it turns out I actually have a personal project that I'm just scheduling some time for, so I think it may just become my Django testing ground! With a little luck I'll write up how I get on.

Update: My first Django site is live