Wonderful article. Well measured and smart. There can be a lot of hate on Rails over "magic", but a lot of it isn't that hard to understand. From a comment o

Wonderful article. Well measured and smart. There can be a lot of hate on Rails over "magic", but a lot of it isn't that hard to understand. From a comment on the article: The obvious example of ‘magic’ in Rails (beyond all the activerecord stuff) that I always mention, is that the controllers (equivalent to Django’s views) don’t take a request parameter in the function definition. They also ‘magically’ render the relevant template without you have to do it explicitly. Well, the first part of that is that Django uses functions and Rails uses methods of an ActiveController subclass. It's just that the things that would go into a request parameter were initialized as class variables with accessors and then the method was run. Now, you don't see the initialization, but it's not as if you ever explicitly pass "request" to a function in Django through urls.py. You just declare functions as taking that parameter, but in urls.py you say: (r'apple/$', 'project.apple.views.apple_view') and "magically" the request object gets passed to that view and magically it's imported into the current context without specifying an import statement. Similarly, one could argue that rendering a template without having to explicitly specify keeps Rails DRY. With Django, there's plenty of opportunity to make things harder to keep track of if you're constantly randomly naming templates. -- What makes James' piece so good is that he realizes that it's not about magic or not. It's about a balance. No magic means you're constantly repeating yourself and leaving yourself prone to errors. Too much magic and people can't understand what's going on. Clearly managed memory isn't too much magic in most people's opinion. But it is magic. Is assuming that the action "apple" of the controller "Fruit" should want a template fruit/apple too much magic? In my opinion, that seems like a sensible conclusion. It's overridable. It follows. The problem is that there's a ton of people that don't seem to realize that Django and Rails aren't that different. People continually want to make silly judgements between the two and claim one the victor - people who usually aren't the ones developing those frameworks. Heck, even DHH has talked about being able to use Rails 3's routing to add Django powered sections so that one could take advantage of GeoDjango's cool spacial stuff if one wanted. The Django core team is never really badmouthing Rails. There just seems to be people who want to fight over whether you have to say "def view(request)" or "def view" when neither is that helpful or that much of a hindrance. Is this how people keep from having to write their applications? Language and framework wars? Me, I keep from writing my applications on HN ;-).