front and back-end web development, Leeds, UK
Richard's Blog - Design, coding and life in Japan
Why you should use Rails 3 and not Django
Submitted by Richard on Sun, 09/05/2010 - 12:28I 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 Wins | Django Wins |
| Bundler | The Admin App |
| Capistrano | Mini-App Architecture (portability) |
| REST | Form 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
- Yahuda Katz blog posts on Rails 3
- Rails 3 Railscasts by Ryan Bates
- Rails 3 Screen Casts
- Django Documentation
- Rails 3 Guide
Tags:
Recent Blog Posts
- Testing controllers in Lithium 2nd Feb 12, 18:19
- Practical Internationalization in Lithium 31st Dec 11, 02:06
- Using OAuth in Lithium 30th Dec 11, 23:47
- How to add your own Tokens from CCK fields in Druapl 7 17th Jun 11, 04:49
- Weaving Lithium #li3 into a legacy PHP application incrementally 5th Oct 10, 11:54
Of course the syntax for
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.
As you can see, it is up to
As you can see, it is up to 20x faster in some areas. More than 10x faster in 6 trials. To be included in Django is a tool for fabric. For the migration pattern in Django is super-easy and fun to use project south.
360 Directory
As for performance. There is
As for performance. There is PyPy project in Python world. It is JITing Python compiler written in RPython. Currently much faster than CPython in many areas and is developing very rapidly now, it will be probably the future of Python. You can check the performance here: http://speed.pypy.org As you can see it is up to 20x faster in some areas. More than 10x faster in 6 tests.
For deployment in Django there is Fabric tool.
For schema migrations in Django there is super-simple and fun to use South project.
Thanks Naos
Yes that is good input, I agree there are great Django solutions to much of those issues out there, I have used some of them including South. I am interested in using Fabric tool, I will give it a look!
Nice comparison
Nice comparison, but frankly, I don’t see how Ruby vs. Python leads to Rails preference over Django. Python 3’s incompatibilities are [very] slowly being addressed, but that’s whole another story — no one distributes Python 3 anyway, so it’s Python 2.7 all the way (and it has a good standing, if you ask me).
As for performance.
_________
davis rivard from machine à café
Thanks for the comment
Agreed on python 3 not yet being mainstream so not really an issuse. Although Ruby vs. Python shouldn't lead a preference it still contributes to it. Of course personal preference is a huge element to this.
Post new comment