» Why Django kicks Ruby on Rails’ collective ass.
Django and Ruby on Rails seem to have surpassed all other frameworks like Turbogears or Symfony and are the talk of the web developing blogosphere, RoR going as far as making Ruby notable again, making it known to many people, as this language was almost unknown in 2004, before RoR’s opening. When I tried to do a quick web app I had to do, I skimmed over the two frameworks, finally deciding with Django to do my work on. As I moved on, I saw that Django, while not as hyped and AJAXy as Ruby on Rails, is much better and workable with than it’s main competitor. Ten Eight reasons why Django kicks Ruby on Rail’s ass.
1. Python.
Python drives Django, as many would know. Each time you write a line of code in a Django app, if it’s not on templates, you’re writing Python. This means that you’re able to use the large base of Python developers worldwide, and also the amazing number of Python libraries, coming from it’s 16 years of being heavily used, going into places such as Google, NASA and even some games such as EVE Online or the great Civilization IV. Furthermore, since Python has a more active userbase and more frameworks, if Adrian Holovaty, Jacob Kaplan-Moss and all of the Django developers suddenly dropped dead after I finish writing this, the porting of the code would be much easier than if Rails’ development stopped, where you would be stuck in the middle of nowhere if you ran into an issue. And who doesn’t want a language which has an implementation called IronPython?
2. Documentation
Django’s documentation kicks everyone’s ass. Not just Rails’. Django has a pretty documentation, easily understandable by both newbie and expert developers. Then, if by chance there’s something which can’t be found in the official documentation, there’s always a great ticketing system where many people posted code snippets and small howto’s, and awesome blogs such as B-List which help a troubled user to do everything from extending the user model, to being a master over generic views. However, Rails’ documentation seems confusing at first, with external tutorials and a massively confusing documentation repository.
Furthermore, the main Django developers decided to make an open book, which they have posted on the web and is open for comments, using a Django based publishing site they built, and some of Yahoo!’s Javascript libraries. The main problem with the many Rails books that there are is that they do not try to complement the Documentation, they are the documentation.
3. Templating.
Since Django’s inception, the templates have been designed so that there is no need to be a programmer to know how to create the templates. This means that the design can be split, making for skinnable sites and the ability to outsource the design to a designer, and not need that designer to pick up a book on Ruby on Rails’ in order to make the site pretty. Furthermore, since Django tries to keep as much coding away from the template as possible, the template’s are most often much more readable than the ASPish or even Cthulhuian .rhtml syntax that Rails’ programmers and designers have to use to design and display the processed information. Django’s system makes for much better cleanness using filters, which modify the way your text will be rendered, and template inheritance, making it easy to make dynamic websites.
4. Speed
Both Python and Ruby developers pride on the fact that both programming languages are fast. While they are slower than C and Java, they are probably the fastest in development times, allowing the developers to see the clear picture and work as fast as possible, avoiding as many errors on the way as they can. However, while both compete fairly in development times, the actual processing speed for a Python program is much faster than a Ruby program, while they are working on this. However, the same thing happens in the frameworks, which clearly show that Django is faster than both Rails’ and Symfony, a PHP framework. This means that your apps will be able to take a hammering better if they’re programmed using Django than if they’re using Ruby on Rails.
5. Free, JustWorksâ„¢ Admin interface
Django doesn’t need any MySQL managers, SQLite command line interfaces or any way to change records on the database, because it already has one. Every app is able to, by uncommenting two lines, have a full fledged admin interface containing all the modules that were written and have been marked for inclusion in it. Not only that, but the models may be modified so they appear differently in the admin panel, as it is fully customisable, making it easy to show some choices as drop down boxes or radio, or filtering by fields, etc. This is why none of the Django screencasts nor any of the tutorials need anything more than Django and a text editor, while you see all of the Rails’ screencasts, which there are lots, always having an open MySQL manager. Oh, and the admin interface in Django is damn hotâ„¢, too.
6. Generic views and feeds
With Django, there is no need to program when the operations being done are listing or editing objects, listing entries by date, or any of the basic CRUD operations, which means that the developer’s time can be spent doing useful things, not just getting simple things from the database, or directly editing fields. Furthermore, since Django was made in a publishing environment, creating RSS feeds is as easy as choosing what you want to pull out from the database and into the feed, and choosing where the feed will be retrieved from. This manages to take away the boredom in creating web apps, which in many cases involves cutting and pasting a lot of code, to create, edit or view, sort and manage items which are mostly alike. Django takes away all of this.
Django also has what they call the Flatpages, making it easier to create and select the URL of unchanging information, such as an about or contact page. Furthermore, it can also be edited, all using the Django admin, which makes it even easier than using HTML, not having to create a file nor edit urls.py to point the URL desired to the flatpage.
7. Better support and server
While both frameworks do not have much usage of big enterprisey databases, Django goes further than Rails on database support, as it supports MS SQL without having to do ugly hacks. Of course, its support for SQLite, MySQL and PostgreSQL is top-notch, with Postgres being used in all of Lawrence’s sites, which get millions of visitors each day. Furthermore, Django supports, thanks to the Python WSGI more webservers, as it gives more choice for the admin and more flexibility on setup. It does work on mod_python, which is a problem Rails has, as when it is used with mod_ruby, it has some security problems when running multiple sites on the same server, or just using FastCGI, which is not always optimal, especially due to configuration.. Further on, each Django process ends up being cheaper than having Ruby processes, meaning faster web apps.
8. Django is (mostly) buzzword free
Django isn’t plagued by buzzwords, as Rails is. Rails’ is to much that it’s own name, RoR has become a massive buzzword everywhere, even by people who will never program anything. Now that programming Rails is what the cool kids do, there is a lost value on a language, as the hype goes on and on. Especially having things like AJAX, Web 2.0, XML-RPC. Ruby on Rail’s ends up coercing developers into using too much AJAX, because “it’s way too easy”. The problem is that you get people trying to use AJAX where it doesn’t belong, and you get the complaints that the Web is going backwards in speed and loading times. However, Django is the balance. You can use RSS, if you want to. You can use AJAX, if you want to. You can even have sitemaps, if you want to.
If you want to be cool, and have loads of friends, snazzy AJAX for login scripts which end up failing when you forget to provide a fallback, or you can try the techie way, and bask in the tub of good code, simple design and choice, while not losing speed or reliability. Not at all.
EDIT: My apologies to Adrian Zolovaty Holovaty. It is Holovaty, as the developer himself says.
.
.
