<p><pre><code> I subscribe to the view that the template language is
for designers and should only allow safe constructs.
</code></pre>
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 <i>another</i> 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.<p>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.<p>It doesn't have anything on Haml, though.
The difference between ActiveRecord and Django models, is ActiveRecord <i>reads</i> the schema. When you're developing, having an ORM create tables and add colums willy nilly is fine.<p>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.<p>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.
Just like Rails has some drop-in "fixes" (i.e. the admin) that don't come with the core, Django does as well.<p>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<p>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".
Interesting. Both are great frameworks. My thoughts are:<p>I like how django lacks all that directory structure and you can easily use a single file for your models.<p>Django templates are way more powerful and safer than erb / haml, etc.<p>I wish there was a port of django templates in ruby. If so my preferred environment would be sinatra + datamapper + django templates.
As a full-time Rails developer I think some of these gripes are valid.<p>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.<p>In terms of templates, HAML/SASS are popular alternatives to ERB. For the admin backend; there are plugins for it.
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 ;)<p>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.
<i>>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><p>I only use django and have never-not used migrations for a project. Thanks god for South. <a href="http://south.aeracode.org/" rel="nofollow">http://south.aeracode.org/</a>
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.<p>as a general rule, i think you should probably do more than 1 simple project before evaluating any framework or language.