In Django, the validation & type coercion would typically happen in a Form object (or, if you're using Django REST Framework, a Serializer). That step at least is outside of the ORM and seems much more explicit to me.

Also, in Django models are explicitly defined. There's no ActiveRecord magic of reading the database to define the model. Which is not to say that AR's approach is bad or wrong, but it is pretty significantly different from Django.

"Explicit is better than implicit"

Hm. I was trying to guess what Ruby was doing and it appears I guessed wrong. Thank you.

I haven't worked with Rails, but have worked extensively with Django and this doesn't seem to be the case. Even though Django is very similar to Rails in some ways, to pretty big differences is that Django seems to be much more explicit in general and (I might be wrong about this) Django seems to be easier to use in a SOA since your controllers (views in Django) are not as tightly coupled to your models.

That's correct. Around the time that Rails became popular, Django was undergoing a major refactoring to remove "magic" and make its underlying logic more explicit.

Further smaller changes have been made since then for the same purpose: explicit over implicit, code or configuration over convention is part of Django's philosophy.

IMO that also makes it easier to graduate from a beginning to an intermediate level use of the framework because while there are sane defaults in many places, in others you're required to define your specific implementation explicitly from the start. It's a tiny bit more code up front, but all the details are exposed and it's obvious how to override default behavior. And at the same time the framework supports keeping your code reasonably DRY and takes care of much of the tedious, repetitive stuff.

There's still tight coupling in some places (ModelForms, for instance, are arguably part of the controller layer and are tightly coupled to the ORM). But they're reasonably optional (you can use plain Django Forms instead of ModelForms in your views or not use the Forms library at all.)

This argument often comes up and I'm genuinely curious why people think Django is less "magic" than Rails, in my experience it has been the opposite.

My experience with Django (for instance: class-based views and admin parts) is actually that you have dozens of magical classes or methods and if you don't know them all, you're screwed. Often when I try to do something, many aswers on StackOverflow boil down to "just override a_method_that_is_hidden_somewhere()" or "just use ListButWithSpecificBehaviorView(), easy you see?".

Are there any specific example you have in mind where Rails do something magical that requires more code in Django but where Django is more explicit?

PS: not trying to start a flamewar, both are OK-frameworks, bla bla bla ;-)

I had a hard time understand how Rails works under the hood by reading the source. No such issue when reading Django source code. Rails magic is really powerful and I got overwhelmed. Maybe its just my Ruby-fu is not strong.

I get the feeling its not your Ruby-fu, but Rails is a lot like trying to jump into the show Supernatural in Season 10. I did some Rails sites early, and now have very little clue what's going on when I read new code. I'm sure I could get it, but its going to be a time investment. This seems to be the way of opinionated frameworks.

It's been awhile since I looked at either but I remember as a beginner I had trouble parsing both the Django source and the Rails source. The rails source was the hardest because I didn't understand ruby and the Django source was hard because I didn't understand python.

I feel like people really forget what it's like to be a beginner when they say "read the source".

"Oh, if you are a beginner, you should work on documentation!"