Rails > Django
Thanks to the new job at bandwidth I’m reacquainting myself with ruby and Rails. After a few weeks of cramming Rails books; I’ve come to a conclusion: Rails is simply much better than Django for my development style. Why?
Convention over configuration
In Django, you can configure everything about the web application but you also have to configure everything. That makes the Django powerfully flexible, but needlessly complicated. Take Django templates. Do they belong to the project, the application, or neither? The answer is: all three.
What we ended up doing was browsing github and google to find examples in other projects; come to a reasonable conclusion on the best current practice (which, at the time, was some directory hacking to store templates in the project directory); and then figure out how to incorporate the configuration into the project and/or application. We were essentially arriving at the same place as convention over configuration, but with non-inherent conventions.
Rails, conversely, just has location in the application for templates. You don’t need to debate it, decide on it, search for it; or even explicitly create it and point to it: it’s just there. Done.
The same with public facing files. I’ve seen django projects do all kinds of interesting hacks to deal with static content. Rails? It has a /public directory already present for handling static content.
It’s as though the Rails developers took the idea of a framework one step further than the Django developers. They both got to the point where you can start doing cool, well organized, object oriented, web development using their respective languages. But Django stopped there to let developers take the framework in any direction; while Rails continued to build in sensible defaults and best practices like inherent testing.
