Thursday, July 25, 2013

Django vs Ruby on Rails - the (un)final smackdown

Having worked with both Django and Ruby on Rails on recent projects, I was able to form some opinions on a question I spent a fair amount of time researching: "What should I use for my next webapp, Django/Python or Ruby on Rails?"

First of all, both are amazing MVC web development frameworks. I've never been so productive doing web development and it's hard to go wrong using either one. I owe an enormous debt to the creators and contributors of/to these open source angels. Also keep in mind that I'm not in any way entering the debate of Python vs Ruby - I consider them equal for the purposes of this exposition. Moreover, performance considerations are equal, any marginal performance advantages you can argue one over the other is vastly out-weighed by the talent of the developers building your web application. Within the foregoing context, here are some pros/cons of each:

Ruby on Rails

  • Pros
    • In general, I found more forum and community support (stack overflow, etc) and found more contributors to common add-ons (gems).

    • Asset pipeline - Rails has a built-in asset packaging tool that compresses/minifies js, css and helps partition these resources among pages for page-load optimization. Note that Django has similar options via contributed packages - example.

    • Though Rails doesn't have much in the way of a built-in admin app (think basic CRUD directly to your tables). There is a great selection of contributed gems (check out rails_admin).

    • Though Rails doesn't have much in the way of a built-in authentication, the de-facto standard gem - devise (using warden) is much more flexible and forward-thinking than django's built-in auth with the ability to authenticate independently for different domains and realms.

    • Model validations with Rails seemed more usable and flexible out-of-the-box. These rules are also easier to apply to form input, whereas with Django, I found myself having to duplicate validation code for persistent data.

    • Rails is more faithful to the MVC design pattern with clear delineation of models, views and controllers. Django's borders seem less defined with four main constructs: view, form, model and templates where the MVC view is somewhere between Django views and templates, and the MVC controller is somewhere between Django views and forms (closer to views), with some unnecessary overlap between Django models and forms.

    • Rails has built-in database migrations (though check out South for Django).

    • Rails has better support for RESTful API's and interfaces out-of-the-box with its resourceful routes.

    • Route/url mapping is clearer and more concise with Rails' resourceful routes.

    • Rails logging for a development environment is deeper and more verbose out-of-the-box giving developers better insight into bugs and/or bottlenecks with profiling info (though check out the django debug toolbar).

    • Rails template system can readily adapt to different implementations - HAML, etc. Though Django seems to be catching up on this.

    • ORM - rails' built-in activerecord is more functional than Django's ORM. For example, I couldn't find a reliable way to accomplish a simple left outer join with Django (without writing SQL). Also Rails' ORM is modular allowing you to choose a particular ORM engine.

    • Rails' console, though slower to start is much more usable because it automatically imports everything you need.

    • More built-in CSRF magic.

    • In general, Rails has more magic built-in (e.g. mapping URL to controller/template name). This can be good or bad depending on your taste but I found the Rails magic overall to be very useful, intuitive and in good taste.

  • Cons
    • Rails is evolving quickly. This is a pro as well, but when it comes to upgrading Rails and included gems, there are some backward-compatibility issues to deal with, compared with the less accelerated (dare I say, more stable?) Django.

    • Somewhat brittle dependencies with gems - I found myself having to deal with gem version conflict issues on rare occasions, though Bundler and RVM made dealing with different versions of Ruby and gems quite enjoyable overall.

Django

  • Pros
    • With Django, I was less concerned with rails' mass-assignment issues since any field not defined/declared in a form will not be considered for persistence. Note that rails behavior can be made compatible to Django in this respect with a special option for the paranoid - config.active_record.whitelist_attributes = true.

    • Faster startup time in the development environment. Rails' models are much more tightly bound to the database schema and there is significant communication/validation with the db before Rails is able to start handling requests.

    • Built-in admin interface - sophisticated and highly extensible/customizable CRUD interface, right out of the box.

    • Good separation of application code and template code. Django forces you to do the heavy lifting outside of templates with minimal procedural capabilities in the template language. This is of course at the expense of flexibility.

  • Cons
    • Django built-in template system is less rich with limited ability to use the programming language within a template. This is reportedly by design to protect against bad coding practices - I get that, but would rather rely on discipline of my team and have the additional flexibility.

    • In general, with Django I found myself asking where is the equivalent of such and such that I used in rails?

Another interesting discussion on this topic.

No comments:

Post a Comment