The first obvious observation is that neither one is universally better than the other. Both have strength and weakness and which one to choose is strictly related to the project requirements.
Before starting
Let’s also clear something out: if you just need to put a couple of pages online for the grocery store around the corner both Django and Ruby on Rails are overkilling due to complexity overhead and resource requirements (that do have a cost in production); Flask or Sinatra might be better alternatives in these scenarios.
I found the following table (that I stole from here) very useful:
| Software | Requirements | Consuming Details |
|---|---|---|
| Django | 80 MB | 40MB one process, 8MB for every thread |
| Ruby On Rails 2.x | 80 MB | 70MB one process |
| Ruby On Rails 3.x | 80 MB | 80MB one process |
| Flask | 30 MB | 20MB one process, 8MB for every thread |
| Sinatra | 40 MB | 30MB one process |
That said, trying Django or Rails might be a good learning experience anyway.
The never ending battle
Just so you know I used Django first as I learned Python before Ruby, then I tried Ruby On Rails when I needed to implement a web application with a good set of APIs since I couldn’t rely on the remote hardware but I could (and I did) exploit the internet connection :)
Documentation: Django is very well officially documented, it’s by far the best documented open source project I’ve ever seen. Rails has documentation too, but in a different way: it relies much more on the community; when you’ll go deep you’ll start appreciating having an official documentation.
Object Relational Mapping (ORM): If you’re not familiar, an ORM is a way to talk with the database that “saves” the developer from using raw SQL. Django ORM is its most criticized aspect around the internet, I guess that my needs where simple and basic enough that I never had any problem. Rails uses an ORM too that is more explicit, meaning that it’ll be more flexible. In my experience there wasn’t very much practical difference.
RESTful API: In short it means that your web application is offering an interface that accepts at least the four major request types: GET, POST, PUT, DELETE. Django usually handles GET and POST, but you’ll have to it by hand it the views. Rails was built around this concept so everything works like it should right out of the box.
Tamplates Language: Djando default template language is a bit naive, because it’s attempting to leave all the logic outside the template, for instance there’s not even a range() function/filter available by default. Of course is very easy to expand that and make a get_range() filter available (snippet). There’s also the possibility, if you were to add this filters too frequently, to easly switch to a more powerful template language like Jinga2 for example. On the other side Rails template language uses plain inline Ruby. Once again for my simple needs were both ok, but I like the curly brackets more than their angular cousins (used by Rails).
Configuration vs. Convention: Django is configuration-driven, its settings module is wonderful, is nothing like Rails that have the configurations scattered all over the project. Rails has a different approach, is convention-driven, which means that it tends to make the “usual” decisions for you. I usually don’t mind writing a few more lines by myself (we are coders after all) and I prefer to be fully in charge and with all cards laid on table since one thing is sure: if I grow enough I will break the framework (whichever I’ll use) and nothing could be done to prevent it.
Up and Running: Both Django and Rails can get you up-and-running in no time, but Rails is a bit more complex to deploy with all its project dependencies and bundled subdependencies.
The Admin: Django comes with admin batteries included, so everything just works like it should and works well. In Rails there are two options RailsAdmin and ActiveAdmin, ActiveAdmin is the new tool and is easy to install and configure and is as powerful as the Django Admin.
Authentication: Django authentication system is included right next to the admin system and it works very well, it handles everything for you just like it should (passwords, permissions, groups, and so on). For Rails >= 3.1 things got more simple but it’s still not as easy as with Django.
Content Management System (CMS): For Django the main one is Django-cms that is fairly well documented, even though I loved it at first I must say that I wouldn’t use it anymore unless the client were to really need a frontend editing interface; the reason is that it will quite constrain the whole project into its structure. After the bad django experience I’m not eager to jump into a Rails CMS so I haven’t tried anyone so far.
Python vs. Ruby: This is not a general point, is very much related to yourself and which one do you prefer to use. It’s personal (full stop). As of right now I feel more confortable with the explicit Python syntax, with you might be the other way around.
Performances: Unfortunatly I can’t address the performance issue since that needs to be accurately mesured (with efforts and time), but I’m confident that both Django and Rails can handle standard performance requirements without making a sound.
Conclusion
Either Django and Ruby On Rails are good and powerful frameworks, but choose carefully beacuse the framework with the specs not matching a project requirements will cost in time (= money) and efforts. Do you need RESTful API? Do you need internationalization? Do you need a CMS? Which are the moving parts of your website? Do you need users to log-in/subscribe? In doubt try them both and form your own opinion.
One last advice that it’s worth sharing and that I got from this talk at the EuroPython2012 is that instead of thinking on how to solve your own problem/project with this or that framework, finding your own solution and only later look for a framework to see which one suits you best, is an approach that will pay very well.
Comments powered by Disqus.