

Thoughts about Rails from a Django guy - lenni
http://lenni.info/blog/2010/07/thoughts-about-rails-from-a-django-guy/

======
samdk

        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.

~~~
catch23
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.

~~~
jmatt
I agree this was frustrating initially. After a certain number of django
projects most of the django devs I know use the heck out of it's modularity.
If the templating system is driving you insane drop in Jinja2 and go. If it
just needs to be tweaked then implement the template command yourself.

I felt confined and frustrated with Django until I realized that it was built
with the intention that developers should just crank code on top of it. And
not just page code - anything that you need. It's more than just an end
product that is just configured, tweaked and templated. Of course ruby similar
in the same way... But in comparison to java and .NET web frameworks this was
a big change.

 _Why couldn't they just write it in python instead of inventing strange
keywords like "ifequal"?_

I think they were trying to get away from the horrid nastiness that had become
php or before that cgi. Yet they still wanted to provide options for
designers. It definitely has a learning curve and requires the programmer to
just roll with it and adopt the "django way". At least until you figure out
you can just move to another templating system.

[http://docs.djangoproject.com/en/1.2/howto/custom-
template-t...](http://docs.djangoproject.com/en/1.2/howto/custom-template-
tags/)

[http://docs.djangoproject.com/en/dev/ref/templates/api/#topi...](http://docs.djangoproject.com/en/dev/ref/templates/api/#topic-
template-alternate-language)

<http://djangosnippets.org/snippets/2063/>

~~~
catch23
Shouldn't the included templating system be the one everyone uses? It doesn't
make sense to include a templating system if everyone will eventually just
replace it with something better. Even though there are alternative rails
templating systems out there, I would say a good 80% of the projects out there
use the default "erb" mechanism for templates -- it's simple, it's ruby, and
it works. Capitalization or minor string manipulation in erb doesn't require
one to write a template filter function somewhere else.

It's also interesting that in Django 1.2, they pulled away the nastiness of
"ifequal" and "ifnotequal". Also, I don't buy their argument that the Django
templating system is easier for "designers". Most designers whom I've worked
with also do designs in other frameworks and Django's system is no more
foreign than jsp, asp, or erb.

~~~
jmatt
_Shouldn't the included templating system be the one everyone uses?_

Agreed. I think they know that this is a weakness. I'd expect it to improve
over time. In a similar fashion to them addressing ifequal and ifnotequal in
1.2.

 _Capitalization or minor string manipulation in erb doesn't require one to
write a template filter function somewhere else._

Personally I'd prefer defining it once somewhere. Then use the function
everywhere. Even with the initial code cost.

I think this is from past bad experiences. I once "repaired" a million plus
line of code enterprise app that had misused some open source code that did
date and number coercion (similar to django.contrib.humanize but for ASP).
Needless to say the code was a mess and nearly the same code had been mixed in
all over the place. The template code, the backend business logic and the asp
C# files. After a few days of regexing then testing then fixing then searching
then repeating. And then dealing with all the edge and special cases - I'll
take a simple defined template function. All that being said - my example is a
gnarly enterprise example involving bad code monkeys. So take it with a grain
of salt - it's likely that the story isn't applicable to a lot of people here.
But still - lesson learned. In the future designers can request template
improvements and I'll deliver.

~~~
catch23
Well, anyone can still write crap code with Django, it doesn't require an
enterprise C# language to produce crap. Django templates still have logic that
needs to be tested & debugged so the template filter functions don't alleviate
all the pain either. Plus, the concept of template filter functions is
available in pretty much all web frameworks out there, but it's more painful
to use if the templating language forces one to write a filter function every
time you need to wield the python language.

------
technoweenie
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
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>). 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
Just to clarify even more, you should be using South
(<http://south.aeracode.org/>), the first thing on that list, and you usually
don't have to write the SQL yourself.

------
kgrin
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".

------
grandalf
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
<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/hel...](http://github.com/eladmeidar/sinatra-
mvc/blob/master/app/helpers/ruty.rb)). 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
oh very cool thanks for the link.

------
matthewcford
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.

------
micaelwidell
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.

~~~
jules
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
> _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/>

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.

~~~
catch23
It's kind of odd that the default subsystems that come with Django are always
replaced with something else -- why doesn't Django include some sane defaults
instead?

~~~
bad_user
This implies that Rails has "sane defaults".

From my experience that's hardly the case ... ActiveRecord (pre 3.0 at least)
sucks big monkey balls compared to Django's ORM. And Rails also doesn't have
anything like the forms API in Django.

------
metamemetics
_> 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/>

~~~
davidwparker
I'm confused. South is all about migrations...

"South brings migrations to Django applications."
-<http://south.aeracode.org/docs/about.html>

------
spooneybarger
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.

~~~
jhickner
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
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>

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

~~~
mrinterweb
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> or things related to
<http://github.com/eventmachine/eventmachine>

