I'm using both on two different customers. I have a preference for Rails.

The project structure of a Rails project is fixed and it's easy to jump into somebody's else project. The structure of a Django project is potentially pure anarchy, good luck with that.

That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortunately that means that you have to waste time by writing those imports. I hated that in Java even if the inevitable Java IDE added them for me.

The ORMs are more or less equivalent. I have a dislike for having to actually type the default scope (not the Django term) in Django as in

  Model.objects.filter(...)

when Rails lets me type

  Model.where(...)

The real time waster is the templating language which in Rails is basically Ruby and in Django is not Python. It's something else much less powerful so you have to either prepare all the data in the controller (which is called a view in Django) exactly as they'll be displayed in the page, or write a templatetag and use it to transform the data inside the page. That loses an unbelievable amount of time. If I count the cumulative hours, days, weeks spent at writing templatetags instead of a couple of Python statements I don't know whether to thank Django developers for the easy money or to roll my eyes because that time is useless.

To recap, Django wastes developer time. It's death by a thousand cuts. I'll never use it for one of my personal free time projects.

Edit: don't be too smart in Rails, that is don't build too much magic and waste the time of the next developer into a quest for finding where something really happens. Write straightforward code and if some method name is created automatically, put a comment hinting at the source.

I've worked with both for years and one thing that always bother me is implicit over explicit in RoR. It can seems easy to write code and it's faster because of that, but reading code is harder, there is too much magic. Given that we spent more time reading code than writing code I prefer the python way.

I've been a Rails dev for almost 10 years and the magic is the worst part. When something just works but I expected another hour of work, I feel like I've fallen into a trap. So, instead of just moving on, I look in the documentation for what just happened.

When you find yourself interacting with the magic parts, it is imperative that you comment what is going on so the next dev, which will probably be you, isn't also surprised.

I could agree with this but I think we're comparing here Django with Rails (the frameworks) not the languages.

But yeah, if I had an option I'd prefer things to be more explicit.

> That's mitigated by the lack of autoloading so you can learn the structure of the project by looking at the import statements at the top of the files. Unfortunately that means that you have to waste time by writing those imports.

Although its been a while, I do remember struggling a lot with autoloading in rails for two reasons: you can't find your dependencies from the code itself and when it breaks down its quite hard to debug. Maybe things are better now with rails and when you get really proficient you know how to find where things are - however that increase the learning curve which is supposed to be a benefit with rails. With django, I can generally look at the imports to see what this module is using. With the help of the right tools I can:

- 'go to definition' of any symbol and 99% of the time land in the source, even of django itself - automatically add imports so you don't have to write them - automatically sort and format imports and see the unused ones

With the optional static typing that is being greatly improved with recent releases, things get even easier.

I prefer this a lot above the rails 'magic', for me it is a huge time saver because my memory is not so good, there is minimal friction moving around between code and is various dependencies to see exactly how its done. With rails I'm more often looking at the docs (not so great) or examples, with django I'm most of the time looking at the source code itself or running the shell (which is very, very good).

> Model.objects.filter(...)

Its called a manager. I understand you don't like to type 'objects', it fits in the rails culture of being allergic to redundancy, though I can't really empathize with it.

> The real time waster is the templating language which in Rails is basically Ruby and in Django is not Python.

I hate both but prefer the django template language. I'm surprised this is such a time waster for you. I think its good practice to not put too much logic in the templates so the division of labor in django is much better imo. But then again, I'm not a good frontend person and have problems with the deeply nested structures in html. Everything can help me simplify the template is a huge timesaver for me, bugs in the frontend code are terribly annoying. Honestly I hate frontend.

> > Model.objects.filter(...)

> Its called a manager. I understand you don't like to type 'objects', it fits in the rails culture of being allergic to redundancy, though I can't really empathize with it.

The point it that the objects method adds zero information to the statement. However it's an opportunity to add a soon to be discovered bug when Django crashes because one forgets to type .objects

They should have made filter a method of all model classes and of the models.Manager class. Same thing for all its sibling methods.

Thanks for the reply. Agreed on the templating side of things - it certainly makes building sophisticated UXs harder.

Great point around project structure and ability to move between codebases - I think the lack of enforced structure in Django absolutely helps increase codebase entropy over time.

> Unfortunately that means that you have to waste time by writing those imports

This is time well spent in my opinion. Everyone, including future you, benefit from it.

One of my biggest gripes in Rails is not being able to do this.

> If I count the cumulative hours, days, weeks spent at writing templatetags

Django has support for Jinja templates so you could just use that and call methods in your templates, which negates the need for most template tags.

I've worked with them both, although Rails has been a while. Some things that stand out to me:

Rails has pretty good code generation. If I want just want to get started and add a birthday field to the settings page, I can run a short one sentence command and it will go off: it will know how to do schema migration, routing, views, controller, etc. This is possible because everything is so straightfoward and consistent. I'm not saying generators are a good way to write your code, its just one example of how rails has very a high level of abstractions.

Django however has the admin. Once you have a model, it will generate a fully functional cms for it and its very tweakable. For a lot of businesses, the admin is quite servicable as a cms or administation tool, and it is a _huge_ timesaver.

I generally prefer django over rails, it just seems all much more explicit and easier to discover to me, however I do agree you can be a lot faster with rails once you learn how things fit together.

I second you on the admin and I'm sorry I forgot about it.

Rails has the optional ActiveAdmin gem but it has basically no automatic integration with the Rails app and it's not included. That means that any Django app has a basic admin and most Rails app don't have one.

To be fair, it's easy to hit the limits of those admins but by baking a user hierarchy in the main web app with a super user, you can use the standard web app for many administration tasks. If you can impersonate users (handy for debugging and you have all their data anyway) you can do a lot of things without an admin interface.

Django is great (and comparable) if you're doing just backend, or have a separate frontend/SPA.

The frontend situation in Django is terribly outdated. Just the templating system is the worst thing I've ever seen, and it doesn't even have an asset pipeline.

Agreed. I’ve had to create dedicated SPAs for several projects recently which is a huge shame. I’d be interested to understand the architectural goals of the Django project moving ahead to see if they’re even interested in solving for this type of problem.