front and back-end web development, Leeds, UK


Richard's Blog - Design, coding and life in Japan

Richard

Why you should use Rails 3 and not Django

Submitted by Richard on Sun, 09/05/2010 - 12:28

I wrote a blog post recently titled 'Django vs Rails' and I had a lot of people read it. In the post I was very much more pro Django, but I do believe Rails 3 changes the outlook somewhat. Over the summer I was able to go to Euro-Python in Birmingham, UK and RubyConf in Tsukuba, Japan. Both gave me a strong feel for where both communities are at and my conclusion is Rails is probably the right choice at this time.

Round 1 - Performance

Django has been known to out perform Rails for some time, but here comes Ruby 1.9 with massive performance enhancements. A rewritten router which is far lighter. A completely cleaned up and leaner Active Support. Active Record even though I was saying was just trying to catch up with Django's filtering style in my last post,  I believe now has actually over taken it. Of course the syntax for filtering and scoping is gorgeous, the calls being made to the database are a lot more intelligent creating less waste. Using eager loading is far easier to use. One session I went to on Advanced Django Models at Europython talked about all sort of jumping through hoops you need to do to get eager loading to play how you would like it.

Rails wins!

Round 2 - Language

Python 3 has been out for ages so it Ruby 1.9. Ruby 1.9 is very backwards compatible and Rails is already running smooth and nicely on the new platform. Many ruby-ists are already diving in head first with 1.9 and are only having small teething troubles. Python 3 on the other hand has huge backwards compatibility issues. Python's main advantage of having so many neat libraries at your finger tips is being damaged in Python 3 by many not being compatible. Django is still not Python 3 compatible putting the language and framework in a sticky position. Good job Matz and team!

Rails wins!

Round 3 - Decoupling

Django has always been heavily decoupled by default. Rails has always been extremely tightly coupled. By default it is still tightly coupled but you can now create your stack as lightly as you want. You can even switch in Sinatra or DataMapper as you need. This is largely done by inheritance rather than by includes. The include method of building your stack in Django is very transparent (which I like), but it can be annoying at times to remember all you need, and this can also get in the way of the code sometimes. But I now feel both are on more of a par now.

Probably on Par!

Round 4 - Templating

I also wrote a blog post called 'Creating Rails like template helpers in Django' talking about helper methods in Rails making it so easy to add custom tags which are a pain in the arse in Django, very reminiscent of JSP. Templating in Erb (Rails) feels very much like you are just writing pure ruby where in Django I almost feel like it is a completely separate templating language. Rails also has the freedom of using HAML. I would give Rails a clear thumbs up in this round.

Rails Wins

Round 5 - Testing

Ruby has always been great for testing, many mainstream testing frameworks have been around in the Ruby world for some time, Shoulda, RSpec, Cucumber and Webrat are some of the main guys. But saying this I also found both unit and functional testing in Django fairly easy also using Beautiful Soup and TestCase. So both are good but Ruby has those extra nice tools that are even becoming the main testing methods of testing even non Ruby sites.

Rails Wins

Round 6 - Extras

Internationalization has finally caught up to Django in Rails now. The action mailer has also been improved. You also have better name spacing options in Rails to make Django like sub apps, but I still prefer the sub app method of app building in Django. Django also has a nice form class which means that validations can be done by form or by model. Although sometimes you can find this code becoming a little bulky and if you are not careful means you can double up your model code.

I still don't like the fact that you have have 2 different types of method helpers in Rails for normal object forms and non object based forms. But then again the helpers themselves seem a little more powerful than Django form tags.

The built in migrations is nice in Rails, but this is easily matched by using South in Django. But then the generators in Rails do end up saving a lot of time in Rails. This helps the agile workflow an amazing amount.

REST  

If you are making an API or wanting to make your app RESTful then nothing beats Rails.

The Django admin app

This is probably the sole reason I may choose to use Django over Rails. If you need a simple backend to control all of your data the Django has this built right in.

Bundler

I know of no other Django dependancy management tool. Rails 3 brings this super simple dependancy management tool to the table - nice.

Capistrano

Even in the non Rails Capistrano is the standard way of deploying apps to your server simply

Rails WinsDjango Wins
BundlerThe Admin App
CapistranoMini-App Architecture (portability)
RESTForm Class
Building API's 

Conclusion

At one point I was leaning more to Django as my framework of choice but for the reasons above I do think Rails has placed itself in a better long term position. It's merge with Merb has meant so much in terms of performance, decoupling and smartness. Both frameworks now have very good documentation. Django is still good and I have one big project in Django which I am not going to switch - still a great framework. The Rails community does seem to have that bit much more energy making it an exciting place to contribute. We won't mention Googles preference for Python at this moment in time though....

Resources

Tags:

Recent Blog Posts

Tags

more tags

Blog Archive