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'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.
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.
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.
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.
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.
I just find it strange that it took the Django project so long to finally realize this. Django 1.2 was released in May 2010 -- we shouldn't be "innovating" on something as basic as an "if" statement on a 15 year old language.
The unfortunate part is that many systems still use Django 0.9 and when one writes code there, you have to remember to use "ifnotequal" and "ifequal" as two different distinct keywords in their templating language. For example, if you were on google app engine and wanted to use their included django templating library, you'd be stuck with that horrible stuff.
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.
I think there are two valid approaches here, depending on the project. One project I'm currently involved with has a team of content/design people who work on Django templates - giving them more power with a template engine like Jinja2 or Mako would introduce nightmares.
On the other hand, when I'm building my own applications the Django template engine seems ridiculously bureaucratic, when I just want to drop in a Python function without reams of template tag boilerplate. That's one of the main reasons why I prefer Flask/Jinja2 for my side-projects (well that, and SQLAlchemy).
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
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.
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.
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.
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".
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...). 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.
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)
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.
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.
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?!
> 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.
Of course those are valid points but we are comparing default feature sets here. Otherwise Rails has a crippled template language, database generated from model and automatic admin too.
Have you actually used Rails? Rails has fragment caching built in and you can use a different template engine very easily (just install the engine xyz you want to use and write templates with extension .xyz instead of .erb)
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?
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.
> 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.
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.
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.
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.
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.
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
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.