Pither.com / Simon
Development, systems administration, parenting and business

Grails vs Django, revisited

Some while ago now, I considered the question of Grails vs Django as my web development framework of choice. Since then I've created a few Django web applications. I've also continued to work on several Grails based projects, new and old.

So with fresh battle experience of both frameworks I thought I'd revisit my previous thoughts to see what I feel needs changing, or not, from my early comparison. You can skip to the conclusion if you want.

Development Ease

Previous: close but a win for Django.

Now: this is definitely a win for Django.

Being able to run a full test suite from scratch in less time than it takes Grails just to start the JVM is such an incredible boost to concentration and hence productivity. Both systems auto-reload changes and both seem to stumble on this fairly frequently (especially with in place plugins for Grails), but again Django's immensely faster full-restart time saves it.

Both work equally well with IntelliJ IDEA and vim, so I can work with either in both of my main development environments.

Many, many other things are different between the two but not such that they give either an advantage over the other.

Technical Features

Previous: Grails won for it's family of resource plugins.

Now: it's much closer, I think just about still in favour of Grails.

Last time I talked about Django admin pages and the Grails resource plugins. With experience, I've hardly used the Django admin pages, although they are nice when I have (and Alexandre pointed out Grails has a plugin doing similar); and Grails has replaced the resource plugins with asset-pipeline plugins.

In the more distant past I've lost many an hour to fighting the old Grails resource plugins, including submitting patches, only a few of which got included. In the last year I've spent many an hour fighting the new Grails asset-pipline plugins, including submitting patches, all of which got included. On a slight Grails aside, I found some pretty major issues with the new asset-pipeline plugins but at least debugging them was much simpler and the maintainer has been a lot more responsive too.

However that's all rather a distraction really because the only point is that Grails has (mostly) working, out of the box static resource handling (caching, compressing, etc); where Django does not. In fact, while I'm aware of a couple of Django plugins that should provide the functionality, I've actually not got around to investing the time to get them working. While my resulting web applications still work, they are definitely poorer without this. I will be addressing this soon, but currently it's a strong negative for Django.

It isn't all bad news for Django though. While working with it I've found it does include an awful lot of little niceties, some cherries on the cake. There are several built in template filters that I've had to write several times myself for Grails. I've had a number of occasions, not just in the templates, where I've thought, "oh, excellent, I don't have to write that myself"; which is always pleasant to discover.

Testing

Previous: a draw.

Now: an easy Django win.

The latest versions of Django now include a better test running setup out of the box which removes pretty much my only complaint. Writing tests in Django works well, feels solid, predictable and includes lots of nice helpers.

For Grails, testing continues to feel like hard work. I've continued to spend time in the last year debugging tests only to find the problem is a quirk of the Grails testing system. Yes this is getting better with newer versions and it's a specific area the Grails team are working on but currently they just aren't there yet.

The only thing I really do miss from Grails testing is Spock but even the great Spock syntax and tools aren't enough to rescue this one for Grails.

Libraries

Previous: a win for Grails (thanks to huge numbers of Java libraries).

Now: a draw.

It may still be the case that there are more things covered by Java libraries than Python, but everything I've needed so far has been readily available; so with experience I'm going to call this a draw.

Developers

Previous: a draw.

Now: still a draw.

I don't think the situation here has changed much.

Deployment

Previous: a win for Django.

Now: very close but revised to a draw.

All of the points I made before still stand - Django is lighter weight and quicker; Grails is simpler to deploy (a single WAR file) and benefits from the JVM.

The changed result is because I've now put several Django apps into production and I really missed the simplicity of WAR deployment. Being able to package everything up in advance into a nice neat bundle and then deploy the identical binary to identical servers and get identical results is really good. I'm yet to discover this deployment simplicity with Django. In fact, Django deployments so far have seemed a bit unpleasant - creating and maintaining Python virtual environments and running Django scripts (in the correct environment) on the machine to collect assets or migrate databases has just felt a bit cumbersome.

I still really like the smaller, quicker Django for smaller deployments and quite dislike the bulky, slow Grails even for big machine, cluster deployments; but the single bundle file deployment has just about pulled it back to a draw.

Experience

Previous: a win for Grails.

Now: a draw.

With a year of gaining Django experience on smaller projects, I've been very pleased with how smoothly it's gone. There have been a couple of odd errors that took a while to track down, but nothing I've had to use a debugger to find (which I do seem to need semi-regularly with Grails).

I still feel more comfortable finding my way around a Grails project (understandable as I have a lot of years of history with it) and that is why Grails is just about holding this one to a draw, even though I'm pretty quick and happy working in either framework now.

Final Conclusion

The updated results are:

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

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

The general trend in these results is that I feel the contest is very much closer than I did before. However the actual numbers have now flipped the winner, just about brining Django out on top!

As I did before, I still think that Django and Grails are very closely matched and if you need to make a choice, basing it on existing infrastructure, language experience or even just flipping a coin will always leave you with a very good and enjoyable web framework to work with.

For me personally, I'm especially enjoying the ease of development from working with Django and I'm going to continue working with it, including making use of it for some much larger client projects in the near future.

Comments

On April 29, 2015, 10:48 p.m. Valentino said...

Thanx for your article!

On May 6, 2016, 4:42 p.m. greg said...

Nice comparison, thanks for that

On Oct. 26, 2017, 4:20 p.m. Akshay Kumar said...

Thanks for this article! Really it's very nice!

Add a comment