The Choice(s)
June 9th, 2008 | Published in Rails, django | 3 Comments
A couple of folks have asked me lately whether, having first worked with Django and now with Rails, I would recommend one over the other. I resisted the impulse because, first, I’m an expert in neither framework and second, because the answer really is: it depends. So, that about wraps it up, eh?
Actually, I think it’s a good think to learn both, or as much stuff as you can, because different approaches and philosophies provide different vantage points for dealing with similar issues. Of course, it’s probably out of the question that newsroom developers can go to their IT folks and say, “This week it’s Django. Next week, Rails. After that, who knows?”
So if you have to choose, consider these factors:
- Do you have in-house expertise in either the framework or the underlying language? If so, take advantage of that. I know I’d still be a Python moron without the near-constant guidance I got from Adrian when I worked at WPNI. I’d be more of a Ruby moron without my fellow developers at the Times.
- Is this your first time with a programming language? Personally, I found learning Python easier than I expected and I found that learning Ruby was easier because I knew some Python. YMMV, of course.
- Are you going to need admin apps for much of what you build? If so, then I think that makes Django more attractive, since the admin is such a nice app and it comes baked-in. (Yes, Rails has scaffolding, but it’s not designed to be a full-fledged admin out of the box.)
Here’s what you don’t have to worry about: finding developers that know either Python or Ruby. There are a good number of them, and these frameworks are fun to work with. You don’t have to worry so much about backend issues: both run fine atop MySQL, Postgres and SQLite databases. SQL Server only? Django’s not gonna be as helpful, although you could always be the person who helps make support for it a reality.
The main philosophical difference between the two that I see in practice is the configuration vs. convention thing. Django doesn’t have, for example, a recommended JavaScript library; it leaves that up to you. Rails also allows you to use pretty much whatever, but it puts Prototype out there as sort of a default that you can override. Your reaction to issues like this will depend a lot on your own personal habits and experiences. So try both (or more). See what you like. Then go with it. Just don’t forget that there are always other ways of doing things, and you can learn a lot from them.
June 9th, 2008 at 12:35 pm (#)
A point I make to folks who ask me this question: one of the best things about Rails and Django is the shallow learning curve. It’s completely reasonable to write a (minimal, but) complete website is a matter of hours. You’ll need to live with your technology choice for quite some time — years, probably — so it makes sense to spend a bit more time upfront being careful about the choice.
It’s well worth anyone’s time to spend a few days or a week playing with each tool, reading available documentation and books, hanging out on IRC channels and mailing lists, etc. Look at the available libraries for Rails/Ruby, Django/Python and think about how they’ll fit into what you’re working on. If your app’s going to involve really heavy XML workflow, the crummy XML tools in Ruby are really going to bite; it’s worth knowing that up front. Think about deployment. Are you going to need to deploy on a JVM? Well, you’re probably going to need to wait at least a couple months until Django runs on Jython, but Rails runs on JRuby today.
Of course, the good news is that if you’re deciding between Django and Rails you really can’t go too far wrong; you’ll be far happier using either than you would rolling something by hand in PHP or (#DEITY forbid) J2EENAMBLA.
June 10th, 2008 at 8:31 am (#)
Right on. My answer to this question is even more straight-forward: The best framework is the one you can convince your bosses to let you have.
Jacob is dead on, though, that there are fundamental functional differences between Rails and Django that may make one preferable to the other depending on your situation. It might be good to document some of those in future posts, particularly for newsrooms. (I know your Python/Django sympathies, Derek, so don’t worry — I’ll keep you honest.)
Rails, for examples, is in many ways a more mature framework. But many people (even the Rails faithful) are starting to feel like it’s becoming a little too bloated and are looking at more stripped down frameworks like Merb. Ruby, however, is far less mature than Python, particularly when it comes to certain types of libraries. It’s also a lot faster, though 1.9 should narrow the gap somewhat there.
The bottom line is you really can’t go wrong. Learning one will give you a huge head start on the other, both in terms of Rails/Django and Ruby/Python.
June 12th, 2008 at 9:14 am (#)
I think the learning curve on both seems to be shallow. At least from what I’ve seen, which isn’t terribly much. After the one-day IRE bootcamp on Django, which kind of jarred everything I’d read in the manual into my brain, I was able to basically rewrite our searchable homicides app in a few hours last night.
Sure, I was able to cheat by using some of the code from the boot camp. But it was also simple to customize using the Django documentation for things like uploading files, etc.
All of the concepts seemed to make sense all of the sudden, which = good.
I love how the two frameworks force you to think about relationships and proper database design. As I said on my blog, things like Caspio seem to encourage you to take the easy route and just plop everything into a single table. You know full well it’d be better to have multiple tables, but it’s kind of a pain in the ass when you’re using Caspio.
It seems to me the harder thing is not learning the frameworks, but, say, learning something like MySQL (I’ve been a MS SQL Server guy) and doing things like importing legacy data, etc. Or if you have legacy data that’s in a single table and you want to convert it into your properly designed NEW database tables.