6 ms·

Thoughts about Rails from a Django guy

73 points by lenni 16y ago

spooneybarger 16y ago
there are drop in admin options for rails similar to what django provides as well as a i massive number of templating engines including ones like liquid which address the concerns in the article. as a general rule, i think you should probably do more than 1 simple project before evaluating any framework or language.
- augustflanagan 16y ago
  As a pretty novice programmer who is trying out Rails for the first time after learning to code with Python and Django, I really enjoyed this. Sure, there may be ways around all of the issues he mentioned, but I think that his initial observations are pretty much right on.
- jhickner 16y ago
  I use both django and rails frequently, and I've been looking for a rails version of django's admin forever. Do you have any links? All I've seen are things like activescaffold, but that's not even anywhere near being comparable.
  - bdon 16y ago
    Typus is excellent, only drawback is weak documentation + the authorization/authentication system lies outside your application. It's extensible enough to add in analytics pages, etc. I use it in every project. http://github.com/fesplugas/typus http://github.com/fesplugas/typus
micaelwidell 16y ago
About two years ago I tried a lot of different frameworks and languages to find which one would suit me best. After having tried various PHP frameworks, J2EE, Perl I arrived at Django/Python. The plan was to continue on to Rails after Django, but I loved Django so much that I couldn't imagine that Rails could be any better. Seems like I was right ;) Like the author, I too think Django's default directory structure doesn't work very well once you start doing bigger projects. But luckily, everything is so loosely coupled that you can change the directory structure entirely without too much work.
- jonknee 16y ago
  > Like the author, I too think Django's default directory structure doesn't work very well once you start doing bigger projects. But luckily, everything is so loosely coupled that you can change the directory structure entirely without too much work. Some of it doesn't even work well for small projects--the first thing I do after ./manage.py startproject is change around settings.py so I can have local settings (namely db stuff) and not have to change things around when I push it to a server.
- limist 16y ago
  For useful, non-trivial directory structure examples for Django projects, be sure to see the Pinax project: http://pinaxproject.com/ http://pinaxproject.com/ Pinax comes with quite a few example projects using a common directory structure, which is very well thought-out, separating media, reusable apps, common templates, etc.
- jules 16y ago
  As somebody who has used both Rails and Django commercially I can safely say that I prefer Rails over Django even though I like Python more as a language. This guy marks several advantages of Rails as weaknesses. Migrations for example. In Django you have to migrate manually, or lose data. Lack of migrations is not an advantage. Templates. The Django template language is one of the worst in existence. It is utterly inflexible and hard to use. It is slowly getting better: now you can use `if a == b` instead of `ifequal a b`. Why not go all the way to a usable and powerful template language?!
  - bad_user 16y ago
    > As somebody who has used both Rails and Django commercially ... In Django you have to migrate manually, or lose data If you've been using Django "commercially", then how come you haven't heard of South? ... http://south.aeracode.org/ http://south.aeracode.org/ Everybody in the community that wants migrations is using it. > Why not go all the way to a usable and powerful template language?! In Django components are more decoupled than in Rails. You can replace that templating engine. Also, Django's templating system is really not that inflexible or hard to use ... quite the contrary, it comes with many things out-of-the-box that aren't standardly provided by other web frameworks ... like the ability to cache page fragments.
kgrin 16y ago
Just like Rails has some drop-in "fixes" (i.e. the admin) that don't come with the core, Django does as well. Dependency management: pip requirements files. Migrations (which the author doesn't like, but are pretty useful on a non-trivial project): South Various other goodies: django-extensions There are constant debates over whether XYZ should be in the core (see: South), or at least better discoverable, but if you're going to use a framework seriously it's worth it to evaluate as "framework + its stable and commonly accepted extras".
technoweenie 16y ago
The difference between ActiveRecord and Django models, is ActiveRecord reads the schema. When you're developing, having an ORM create tables and add colums willy nilly is fine. DataMapper took this approach initially, and was basically unusable in production because all it could do was create and drop tables. They've since added a handy upgrade method, and even ActiveRecord style migrations. Personally, I like keeping the model and schema separate. I rarely need a giant list of columns at the top of my model. Luckily, Rails 3 will work great with DataMapper or Sequel (two fine alternatives to AR) if that's how you want to roll.
- hbien 16y ago
  Just clarifying, Django models only create the initial tables/columns of a model after running the `syncdb` command. If you add fields later on, you'll need to write the SQL to add the columns yourself (http://code.djangoproject.com/wiki/SchemaEvolution http://code.djangoproject.com/wiki/SchemaEvolution). It won't try to be smart and automatically migrate your db for you. I haven't used DataMapper in a few years, but I remember their initial approach was to be smart and automagically add/remove any required columns/tables willy nilly.
  - bdr 16y ago
    Just to clarify even more, you should be using South (http://south.aeracode.org/ http://south.aeracode.org/), the first thing on that list, and you usually don't have to write the SQL yourself.
toadytim 16y ago
Node.js is changing the game, Ruby and Rails are just the new Cobol.
- stevejalim 16y ago
  HTTP://WWW.COBOLONCOGS.ORG/INDEX.HTM
- mrinterweb 16y ago
  Comparing Node.js to Ruby on Rails is as useful as comparing apples to oranges. Node.js is not a web framework. Node.js has a wonderful paradigm for evented programming, but that does not mean you can not also have evented programming with Ruby or Rails. Take a look at http://github.com/igrigorik/async-rails http://github.com/igrigorik/async-rails or things related to http://github.com/eventmachine/eventmachine http://github.com/eventmachine/eventmachine
samdk 16y ago
I subscribe to the view that the template language is for designers and should only allow safe constructs. As someone who does both design and programming, I hate template systems that do this with a passion. I don't want to have to learn another language just so I can write templates. Especially when that language makes me jump through hoops to do various simple tasks the designers didn't anticipate--which is the case with every such language I've used. Erb is one of the nicer templating systems I've used. I've never had any trouble getting it to do exactly what I want it to do, and I've never had it behave in a way I didn't expect--which is another advantage to having it just use Ruby. It doesn't have anything on Haml, though.
- stonean 16y ago
  I wrote something, better described as an attribute language, that fits the idea of a 'template language is for designers' called RuHL. http://docs.stonean.com/page/ruhl http://docs.stonean.com/page/ruhl
- tene 16y ago
  This is one of the reasons I'm fond of Perl's Template::Declare. It's a declarative syntax for generating HTML that's still just plain Perl. http://search.cpan.org/~sartak/Template-Declare-0.43/lib/Template/Declare.pm http://search.cpan.org/~sartak/Template-Declare-0.43/lib/Tem... I certainly understand the use case of more-limited and embedded template languages, for working with designers or people less-comfortable with actual programming, or whatever, but when I'm just working on my own, or only with other programmers, Template::Declare works so much more nicely for me.
  - zbrock 16y ago
    There's a ruby equivalent that's pretty nice called Erector: http://erector.rubyforge.org/ http://erector.rubyforge.org/ http://pivotallabs.com/users/alex/blog/articles/1029-why-wouldn-t-you-use-erector- http://pivotallabs.com/users/alex/blog/articles/1029-why-wou...
- catch23 16y ago
  It's funny the author put templating as one of the things he dislikes about rails, especially when the Django templating system is probably one of the worst (of all templating systems out there). They invented their own pseudo language for templating so anything more complicated requires you to write your own special helper functions. I remember back in Django 0.9 (which is still fairly recent), I had to write template library code to do a nested loop over a data structure. Why couldn't they just write it in python instead of inventing strange keywords like "ifequal"? Every time I use django templates, I have to look up documentation on how to do something as simple as string/number comparison. When I write Myghty templates, I'm writing python on top of html and it just feels so much nicer this way.
matthewcford 16y ago
As a full-time Rails developer I think some of these gripes are valid. I have tried to get away from AR for a long time, with other ORMs such as DataMapper or Sequel, and more recently Mongoid. The AR in Rails 3 has adopted some of the good bits from both DM and Sequel, so that might make it more pleasant to work with. In terms of templates, HAML/SASS are popular alternatives to ERB. For the admin backend; there are plugins for it.
metamemetics 16y ago
>migrations: I can see how this could come in handy but in my case this was yet another extra thing I had to keep tabs of I only use django and have never-not used migrations for a project. Thanks god for South. http://south.aeracode.org/ http://south.aeracode.org/
- davidwparker 16y ago
  I'm confused. South is all about migrations... "South brings migrations to Django applications." -http://south.aeracode.org/docs/about.html http://south.aeracode.org/docs/about.html
grandalf 16y ago
Interesting. Both are great frameworks. My thoughts are: I like how django lacks all that directory structure and you can easily use a single file for your models. Django templates are way more powerful and safer than erb / haml, etc. I wish there was a port of django templates in ruby. If so my preferred environment would be sinatra + datamapper + django templates.
- johnnygood 16y ago
  http://ruty.rubyforge.org/ http://ruty.rubyforge.org/ Ruty hasn't really been maintained, but it is pretty close to Django's templating system. Apparently, there's even been a little work to get it together with Sinatra (http://github.com/eladmeidar/sinatra-mvc/blob/master/app/helpers/ruty.rb http://github.com/eladmeidar/sinatra-mvc/blob/master/app/hel...). I haven't used Sinatra, but I have played with Ruty and it's pretty nice and supports things like Django-style inheritance. It's a pity it never took off and this isn't a complete answer to your desire, but it might be an interesting place to look around.
  - grandalf 16y ago
    oh very cool thanks for the link.
- carbon8 16y ago
  There's also mustache (http://github.com/defunkt/mustache http://github.com/defunkt/mustache) which has some similarities to django templates and is pretty popular. "safer than erb / haml, etc" Are you are referring to auto-escaping strings? If so, in Rails 3, this is on by default, and for Haml without Rails it's a simple setting.
  - grandalf 16y ago
    I use Mustache and like it very much, only I find that I wish it offered support for a few of the features in Django templates such as dot notation. I was referring to the auto-escaping as well as to the inability to run arbitrary code inside a template (for all I know this feature is added to the newest versions, though)

73 points by lenni 16y ago

there are drop in admin options for rails similar to what django provides as well as a i massive number of templating engines including ones like liquid which address the concerns in the article. as a general rule, i think you should probably do more than 1 simple project before evaluating any framework or language.

augustflanagan 16y ago
As a pretty novice programmer who is trying out Rails for the first time after learning to code with Python and Django, I really enjoyed this. Sure, there may be ways around all of the issues he mentioned, but I think that his initial observations are pretty much right on.
jhickner 16y ago
I use both django and rails frequently, and I've been looking for a rails version of django's admin forever. Do you have any links? All I've seen are things like activescaffold, but that's not even anywhere near being comparable.
- bdon 16y ago
  Typus is excellent, only drawback is weak documentation + the authorization/authentication system lies outside your application. It's extensible enough to add in analytics pages, etc. I use it in every project. http://github.com/fesplugas/typus http://github.com/fesplugas/typus

micaelwidell 16y ago

About two years ago I tried a lot of different frameworks and languages to find which one would suit me best. After having tried various PHP frameworks, J2EE, Perl I arrived at Django/Python. The plan was to continue on to Rails after Django, but I loved Django so much that I couldn't imagine that Rails could be any better. Seems like I was right ;) Like the author, I too think Django's default directory structure doesn't work very well once you start doing bigger projects. But luckily, everything is so loosely coupled that you can change the directory structure entirely without too much work.

jonknee 16y ago
> Like the author, I too think Django's default directory structure doesn't work very well once you start doing bigger projects. But luckily, everything is so loosely coupled that you can change the directory structure entirely without too much work. Some of it doesn't even work well for small projects--the first thing I do after ./manage.py startproject is change around settings.py so I can have local settings (namely db stuff) and not have to change things around when I push it to a server.
limist 16y ago
For useful, non-trivial directory structure examples for Django projects, be sure to see the Pinax project: http://pinaxproject.com/ http://pinaxproject.com/ Pinax comes with quite a few example projects using a common directory structure, which is very well thought-out, separating media, reusable apps, common templates, etc.
jules 16y ago
As somebody who has used both Rails and Django commercially I can safely say that I prefer Rails over Django even though I like Python more as a language. This guy marks several advantages of Rails as weaknesses. Migrations for example. In Django you have to migrate manually, or lose data. Lack of migrations is not an advantage. Templates. The Django template language is one of the worst in existence. It is utterly inflexible and hard to use. It is slowly getting better: now you can use `if a == b` instead of `ifequal a b`. Why not go all the way to a usable and powerful template language?!
- bad_user 16y ago
  > As somebody who has used both Rails and Django commercially ... In Django you have to migrate manually, or lose data If you've been using Django "commercially", then how come you haven't heard of South? ... http://south.aeracode.org/ http://south.aeracode.org/ Everybody in the community that wants migrations is using it. > Why not go all the way to a usable and powerful template language?! In Django components are more decoupled than in Rails. You can replace that templating engine. Also, Django's templating system is really not that inflexible or hard to use ... quite the contrary, it comes with many things out-of-the-box that aren't standardly provided by other web frameworks ... like the ability to cache page fragments.

kgrin 16y ago

Just like Rails has some drop-in "fixes" (i.e. the admin) that don't come with the core, Django does as well. Dependency management: pip requirements files. Migrations (which the author doesn't like, but are pretty useful on a non-trivial project): South Various other goodies: django-extensions There are constant debates over whether XYZ should be in the core (see: South), or at least better discoverable, but if you're going to use a framework seriously it's worth it to evaluate as "framework + its stable and commonly accepted extras".

technoweenie 16y ago

The difference between ActiveRecord and Django models, is ActiveRecord reads the schema. When you're developing, having an ORM create tables and add colums willy nilly is fine. DataMapper took this approach initially, and was basically unusable in production because all it could do was create and drop tables. They've since added a handy upgrade method, and even ActiveRecord style migrations. Personally, I like keeping the model and schema separate. I rarely need a giant list of columns at the top of my model. Luckily, Rails 3 will work great with DataMapper or Sequel (two fine alternatives to AR) if that's how you want to roll.

hbien 16y ago
Just clarifying, Django models only create the initial tables/columns of a model after running the `syncdb` command. If you add fields later on, you'll need to write the SQL to add the columns yourself (http://code.djangoproject.com/wiki/SchemaEvolution http://code.djangoproject.com/wiki/SchemaEvolution). It won't try to be smart and automatically migrate your db for you. I haven't used DataMapper in a few years, but I remember their initial approach was to be smart and automagically add/remove any required columns/tables willy nilly.
- bdr 16y ago
  Just to clarify even more, you should be using South (http://south.aeracode.org/ http://south.aeracode.org/), the first thing on that list, and you usually don't have to write the SQL yourself.

toadytim 16y ago

Node.js is changing the game, Ruby and Rails are just the new Cobol.

stevejalim 16y ago
HTTP://WWW.COBOLONCOGS.ORG/INDEX.HTM
mrinterweb 16y ago
Comparing Node.js to Ruby on Rails is as useful as comparing apples to oranges. Node.js is not a web framework. Node.js has a wonderful paradigm for evented programming, but that does not mean you can not also have evented programming with Ruby or Rails. Take a look at http://github.com/igrigorik/async-rails http://github.com/igrigorik/async-rails or things related to http://github.com/eventmachine/eventmachine http://github.com/eventmachine/eventmachine

samdk 16y ago

I subscribe to the view that the template language is for designers and should only allow safe constructs. As someone who does both design and programming, I hate template systems that do this with a passion. I don't want to have to learn another language just so I can write templates. Especially when that language makes me jump through hoops to do various simple tasks the designers didn't anticipate--which is the case with every such language I've used. Erb is one of the nicer templating systems I've used. I've never had any trouble getting it to do exactly what I want it to do, and I've never had it behave in a way I didn't expect--which is another advantage to having it just use Ruby. It doesn't have anything on Haml, though.

stonean 16y ago
I wrote something, better described as an attribute language, that fits the idea of a 'template language is for designers' called RuHL. http://docs.stonean.com/page/ruhl http://docs.stonean.com/page/ruhl
tene 16y ago
This is one of the reasons I'm fond of Perl's Template::Declare. It's a declarative syntax for generating HTML that's still just plain Perl. http://search.cpan.org/~sartak/Template-Declare-0.43/lib/Template/Declare.pm http://search.cpan.org/~sartak/Template-Declare-0.43/lib/Tem... I certainly understand the use case of more-limited and embedded template languages, for working with designers or people less-comfortable with actual programming, or whatever, but when I'm just working on my own, or only with other programmers, Template::Declare works so much more nicely for me.
- zbrock 16y ago
  There's a ruby equivalent that's pretty nice called Erector: http://erector.rubyforge.org/ http://erector.rubyforge.org/ http://pivotallabs.com/users/alex/blog/articles/1029-why-wouldn-t-you-use-erector- http://pivotallabs.com/users/alex/blog/articles/1029-why-wou...
catch23 16y ago
It's funny the author put templating as one of the things he dislikes about rails, especially when the Django templating system is probably one of the worst (of all templating systems out there). They invented their own pseudo language for templating so anything more complicated requires you to write your own special helper functions. I remember back in Django 0.9 (which is still fairly recent), I had to write template library code to do a nested loop over a data structure. Why couldn't they just write it in python instead of inventing strange keywords like "ifequal"? Every time I use django templates, I have to look up documentation on how to do something as simple as string/number comparison. When I write Myghty templates, I'm writing python on top of html and it just feels so much nicer this way.

matthewcford 16y ago

As a full-time Rails developer I think some of these gripes are valid. I have tried to get away from AR for a long time, with other ORMs such as DataMapper or Sequel, and more recently Mongoid. The AR in Rails 3 has adopted some of the good bits from both DM and Sequel, so that might make it more pleasant to work with. In terms of templates, HAML/SASS are popular alternatives to ERB. For the admin backend; there are plugins for it.

metamemetics 16y ago

>migrations: I can see how this could come in handy but in my case this was yet another extra thing I had to keep tabs of I only use django and have never-not used migrations for a project. Thanks god for South. http://south.aeracode.org/ http://south.aeracode.org/

davidwparker 16y ago
I'm confused. South is all about migrations... "South brings migrations to Django applications." -http://south.aeracode.org/docs/about.html http://south.aeracode.org/docs/about.html

grandalf 16y ago

Interesting. Both are great frameworks. My thoughts are: I like how django lacks all that directory structure and you can easily use a single file for your models. Django templates are way more powerful and safer than erb / haml, etc. I wish there was a port of django templates in ruby. If so my preferred environment would be sinatra + datamapper + django templates.

johnnygood 16y ago
http://ruty.rubyforge.org/ http://ruty.rubyforge.org/ Ruty hasn't really been maintained, but it is pretty close to Django's templating system. Apparently, there's even been a little work to get it together with Sinatra (http://github.com/eladmeidar/sinatra-mvc/blob/master/app/helpers/ruty.rb http://github.com/eladmeidar/sinatra-mvc/blob/master/app/hel...). I haven't used Sinatra, but I have played with Ruty and it's pretty nice and supports things like Django-style inheritance. It's a pity it never took off and this isn't a complete answer to your desire, but it might be an interesting place to look around.
- grandalf 16y ago
  oh very cool thanks for the link.
carbon8 16y ago
There's also mustache (http://github.com/defunkt/mustache http://github.com/defunkt/mustache) which has some similarities to django templates and is pretty popular. "safer than erb / haml, etc" Are you are referring to auto-escaping strings? If so, in Rails 3, this is on by default, and for Haml without Rails it's a simple setting.
- grandalf 16y ago
  I use Mustache and like it very much, only I find that I wish it offered support for a few of the features in Django templates such as dot notation. I was referring to the auto-escaping as well as to the inability to run arbitrary code inside a template (for all I know this feature is added to the newest versions, though)