[This is the second part of this post]

Getting back from Symfony to Ruby-on-Rails was a big relief! There is no comparison between Ruby and PHP. Anything said on the matter is wasted. Anyway since I had my troubles solved by the hosting company, now I had my first RoR application running on the server. Then I tried to elaborate it, and like immediately found a problem. The problem was internationalization(i18n)! It seems that Rails was not developed with i18n in mind from the beginning and its current version does not support it! You have to hack your way to it. In my mind i18n is a big and necessary feature for web. After all it is the World Wide Web! It turns out that Rails has a major problem with i18n what goes down to the language itself. Ruby does not support unicode for string representation. (actually it does but with the use of a module, not natively). However in version 2.2 of Rails, which is currently the edge version, they included basic i18n support. This meant that I had to use the “unstable” branch of Rails – which I did! Checked out the way i18n support was implemented and found it very basic. This is by design. The developers of Rails want to give you a basic i18n support that you will be able to extend depending on your needs.

Trying to setup version 2.2 on the server gave me headaches again. Also the fact that on windows rails is damn slow started to be really disturbing. If you develop on Windows beware that typing “rails” or “rake” on the command line takes 6 seconds on a P4 2.6GHz no matter what. And these are the command you write all the time! This is a problem that only Rails on Windows has, and its probably because Rails expect a much faster file system layer that the one Windows XP provide.

If you develop on Windows beware that typing “rails” or “rake” on the command line takes 6 seconds on a P4 2.6GHz no matter what. And these are the command you write all the time

I remembered that in the past I had look at a Python based web framework that was supposed to copy the design of Rails. Usually copycats are always worst that the original, and the fact that is was trying to be Rails was a turn away for me. However I was quite sure that it supported i18n natively. So I though it was time to take a second look at django!

It was true! django supported i18n and in a way that I was used to. It uses gettext. Period! Python is full unicode and you are ready to go. But how does it stand on all other sides? Is it just a copy of Rails? Thankfully not! Django is all MVC and stuff but it is not Rails. I find django a bit lower level that Rails, and to a point that makes it flexible and powerful. Working with Rails (especially at the beginning) you get a feeling that you don’t have a clue what goes on under the hood and how things you do impact your project.

On the other hand django is always straight forward. Maybe its the language, maybe its the awesome tutorial and documentation on the main site, but it gives you from the start a feeling that things are done as it should.

It was true! django supported i18n and in a way that I was used to. It uses gettext. Period!

Rails is all high level and easy to do simple things, but it kind of does specificaly only what it was designed to do. For example when I was developing my application on Rails I used my local webserver and tested the site at http://127.0.0.1/ which was ok. When I tried to deploy it on my host, I used a subdirectory under my main URL and routes went crazy! I was looking around the net for a solution and it turned out it was a common problem with no good solution. At least what I read, didn’t work for me. So even going from http://my.page.com/ to http://my.page.com/myapp/ causes problems! Rails was that.. it forces you to do many things its way, and it can’t have possibly have a way for everything I might come up with.

What django does not have, and I loved in Rails, is migrations. Rails uses migrations to evolve the database schema. This is not something extraordinary. It just forces you to write scripts that evolve the schema, indeed of messing with the schema itself. For every evolution you write, you also have to write a script to undo it. This way Rails can convert your schema to any version you like. It is basically what every database developer was doing manually, but now it is automated and you don’t write in SQL but in Ruby which preserves the database implementation agnostic nature of Rails. For django I found django-evolution that does something like the above, but it still under development.

What django does not have, and I loved in Rails, is migrations.

Even if Django started one year after Rails, it seems to me like it is the best choice. There is nothing missing from it. Its design is clean and simple at most of its parts. I often find myself thinking : “hey thats how I would do it, too!”. That is always a good sign. Maybe its Python that I like so much, and understand almost naturally, but I also think that the documentation is a gem. Actually I think that its one of the best documentations for opensource projects. When Rails stops at screencasts, django gives you a complete tutorial that does not stands at the top of things but elegantly dips you to important details. Later on the documentation solves every question that comes up by a simple search. I don’t know how they did but they seem to have thought of everything before you ask.

Right now I work solely with django and I still find it awesome…

django, python, ruby, rails, ruby-on-rails, ror