No conference which discusses the Web can consider itself cutting-edge these days unless at least a couple of the speakers make reference to Ruby on Rails. For those who haven’t come across it, Ruby is a very dynamic programming language which has been around for a long time, but because it originated in Japan, it’s taken a while to gain popularity in non-Japanese-speaking parts of the world. Rails is a framework which takes advantage of the dynamic nature of the language to map SQL databases neatly onto Ruby objects. It has scripts which create a lot of standard stub code for you, and so in general it makes it very easy to create web applications based around a SQL database back-end, which an awful lot of web apps are, nowadays.
I wrote briefly about Ruby on Rails three months ago, and since then I’ve been sipping at the kool-aid – watched the intro videos, bought a Ruby book, and played a bit with the software – but I never quite got a taste for it. Ruby is so named because it was meant to be a better PERL, and it certainly is that, but I think there’s a few too many Perl-isms still lingering in the background. Ruby enthusiasts claim that it’s a ‘pure’ object-oriented language, more like Smalltalk than most of its competitors, because everything is an object, so you can do things like calling a method on an integer:
5.upto(10) { |i| print i }
but somehow this just doesn’t feel very natural to me. You can do some lovely things in Ruby, but I don’t think a language can lay much claim to purity when it still has things like the global $_ variable from PERL.
And so I’ve been very pleased to discover Django, which is a very similar framework that slightly pre-dates Ruby on Rails, and which is based on Python rather than Ruby. Python has been one of my favourite languages for a long time – I first used it in 1991 – and to my mind it’s rather nicer than Ruby for most things. It’s much more widely known, and all the benchmarks I’ve seen also show Python as rather faster than Ruby, and Django as higher-performance than Rails.
Django works the opposite way to Rails; you create particular kinds of objects in Python and run a script which produces the SQL tables which store them for you. In practice this doesn’t make a huge difference. The Rails approach can be more flexible, but with Django’s you get all your canonical source code in the same language. They both have their merits. But the default framework that Django produces is much more useful than anything you get for free with Rails; it provides quite a nice ‘admin’ interface which you can start using immediately for entering data without grimacing too much about the user interface.
My wife Rose needed to store some data in several related tables and access them from home and from the University. In one day I was able to take her data, which was mostly in tables in Word documents and get it via Excel, text files, and some Python scripts into a MySQL database. Django provided the web front end and by the end of the day she was entering her data via her browser into a set of inter-related tables with various conditions attached. I was working in the next room and from time to time I’d come in and say – “Look – there’s a search box now!”.
Remember that this was my first attempt at using the platform. Now, of course, I’ll be tinkering with it for ages, but the ability to get something up and running and useful so quickly is a great tribute to Django’s design. I also have a feeling, though I haven’t tested this yet, that much of Django might be more useful than Rails for any web apps which are not based on a SQL database.
Anyway – highly recommended.
RSS feed
It’s always good to look around. Let me dispel a few misconceptions, though.
Yes, Ruby does have a number of Perl-like aliases, but all but a very few are truly rarely used in the wild. Look at the source code for Rails or any of the Rails open source applications. It’s just not an issue because people don’t use it. Secondly, the motivation for Ruby was never merely to create “a better Perl”. Matz has been inspired by a wealth of sources (yes, Perl is one of them, so is Lisp, so is Smalltalk, etc). His stated motivation for the language has always been to make the programmer happy.
Also, Django first saw the light of day about 1 year after Rails. So no, it certainly doesn’t predate it. At least not in the sense that matters: being available to the public. And what benchmarks are those that show Django to be faster than Rails? I’d love to read one of those.
In any case, different minds consider different things beautiful. I think its great that the Django guys are offering a somewhat similar experience to Rails in Python instead of Ruby.
Nice comparison as I recently discovered Django recently and was going to move into Rails in the next few months.
One problem I’ve found with “cutting-edge” Python and Ruby platforms/frameworks like this is finding the hosting that supports it. Django at the moment needs root access to install the development version – root on standard shared hosting isn’t an option – regardless of whether the provider allows Python.
It’s going to be a few years yet before these new scripting frameworks get anywhere but when they do I think they’ll certainly add a richness to the options we currently have around.
Thanks guys – some useful comments.
I know that Matz (the creator of Ruby) is one of the people pushing for it to lose some of its more Perlish roots, and has suggested that some of these may disappear from the language in time, which is all to the good.
There’s another good comparison of the two here by Sam Newman, for those who haven’t seen it.
I can’t now find the Django/Rails benchmarks that I’m sure I saw somewhere. I’ll keep poking around. There are quite a few Ruby/Python ones around though, and while most of them are not very scientific, I don’t remember any that show Ruby being faster. (Here are a few: one, two, three, for example). But, of course, speed isn’t everything or we wouldn’t be using interpreted languages at all, and the underlying speed of the language doesn’t tell you about the overall performance of the framework.
I think you’re right, David, that Django became public after Rails, though it looks as if the original development on them started at about the same time; I got the dates confused on that one.
We created Django in fall 2003 and have used it on a variety of production sites for our newspaper Web operation, solving a myriad of common Web-development problems in a generic fashion, particularly in the arena of content-management. It’s a relatively new kid on the block in the open-source community, but the core concepts and design decisions are mature. Simon Willison and I, who created it, are no strangers to Web development.
David is right, obviously, that Rails has been available *open-source* for longer. But I can use that same argument to say more people, worldwide, have been using Python than Ruby for longer.
Of course, I don’t want to start any language wars.
The cool thing about Python — well, one of the many cool things — is the wealth of excellent open-source libraries for it, including dozens that ship with Python itself. It requires no external libraries to, say, output CSV or ZIP files via Django. If you want to do something in Python, chances are somebody very smart has already implemented the library.
For example, a member of the Django community added XML-RPC support simply by hooking into Python’s built-in XML-RPC libraries. http://code.djangoproject.com/ticket/547
I expect to see much, much more of this sort of thing.
As for performance, I can’t help but point out this article I saw the other day:
http://www.peterbe.com/plog/ruby-and-python-benchmarked
“But, please notice that this is a Ruby coder and yet his Python implementations are always faster.”
It always amazes me that people like to quibble about weather or not Django predates Rails or vice versa. It’s basically a low-key version of the text editor flame war, and it annoys me. Besides, timeline isn’t everything: PDP-11 predated Linux, for example. I use Django because I get paid to develop it, sure, but I use it for personal projects because it lets me Get Shit Done.
I certainly can’t imagine web development without Django’s automatic admin interfaces, kick-ass URL dispatch, or Python’s amazing libraries (PIL, ReportLab, …) — but does that mean that Django is “better” than Rails? For me, yes, but who gives a shit what I think is better?
The problem when we start arguing we ignore the *far* more productive discussions we *could* be having. For example, say I discover that Framework A is faster than Framework B (how I would measure something like that objectively I don’t know, but bear with me). I could either brag about how much “better” A is, or I could spend some time looking into *why* A is faster in the interests of helping B get better, too.
Not to be cheesy, but I submit that as framework developers our job is to help website developers make better web sites, and when we instead focus our energies on arguing over who predated what we’re not serving our communities.
David, I’d love to know what you think we could do to improve Django. As another developer wrestling with the same issues we do, I think we could learn a lot from you. I’d obviously be more than happy to share my thoughts on Rails should you be so inclined…
I agree with Jacob.
The “faster” arguments are generally nonsense since there are so many scenarios, and different usage patterns can lead to radically different performance figures. In addition, if execution speed were the only issue, we’d all still be coding in assembler. There are obviously other things to optimize besides execution speed, like developer time or overall speed and robustness of the development cycle.
As for the merits of the underlying language: Ruby exposes some nice features that are hard to get to in Python, but I’ve got ten years’ sunk cost in Python development, so that biases me towards staying with it even if Ruby is slightly better. If, at some point, I’ve got an itch that only Ruby can scratch, I’ll adopt it. Haven’t seen that so far, but it’s an excellent language and I might well have a different view if I were starting from scratch with both.
What’s much more interesting to me is a factual discussion about when RoR is more appropriate, when Django is is a more suitable choice, when UCW, and so on. What’s hard in Django that’s easy in RoR, and vice-versa?
I’ve enjoyed playing with both Ruby and Python and with Rails and Django. The one thing I like a bit better about Django is that you use code to represent your models and Django generates the SQL. Rails takes the opposite approach, which is maybe great for someone who thinks well in SQL, but I think better in code.
Both Rails and Django can be be run on at least some shared web hosts. I’ve run both on DreamHost:
http://marc.abramowitz.info/archives/2006/11/14/setting-up-django-on-dreamhost/
http://marc.abramowitz.info/archives/2005/07/06/dreamhost-has-added-ruby-and-ruby-on-rails/
I’d bet that they work on a lot of other shared hosts with a few mods too. If not, you could just install Linux on an old box (or use a live CD like Ubuntu, etc.) and those make good environments or on OS X you could use something like Locomotive (http://locomotive.raaum.org/).