4 ms·

I have been playing around with django for the first time in almost 5 years recently, and it’s so much more productive. Wondering if I should try out rails.

faraaz98 4y ago
Compared to Rails, django will feel like fastapi Imo
- tommica 4y ago
  What does that mean?
  - devoutsalsa 4y ago
    Django is more comprehensive than FastAPI in terms of features and use cases it tries to address, so I assume they mean Rails offers more than Django. More != better.
danmaz74 4y ago
From a very long time rubyist: if you care a lot about code elegance, I think you could like ruby/rails more. If for you it's more important that there is only one correct way to do things, then probably sticking with python /Django makes sense.
- chairmanwow1 4y ago
  Honestly code elegance is less important than raw productivity.
  - danmaz74 4y ago
    My point is that your productivity with a given tool also depends on your own preferences/cognitive style. Between Ruby/Rails and Python/Django, my assessment, even if I don't know the latter anywhere as well as the first, is that your results will depend a lot on your preferences and cognitive style.
pmontra 4y ago
I'm working with both. Django feels like a loose set of tools. That could be bad or good. You have to take more architectural decisions, every project can end up with a very different structure. You can split it into sub applications each one with its own urls file, models, controllers and migrations. Tests lay in the same directory of code. The templating language is quite constrained and inflexible. The source of truth of the database are the models and I discorage using inheritance in models or you end up with a database that no other application will ever be able to understand, humans included. The ORM feels verbose. The admin tool is good. No tools for deployment, maybe docker? In general there is a feeling of overengineering everywhere as if it was designed to keep up with every possible use case. Rails is more constrained, it's really on rails. Again, this can be both bad and good. Two projects will look the same except for those companies that adopt the services / commands / etc sub structure of the code and the ones that stick to the plain models directory, possibly lib. The source of truth of the db is the db and if you want to turn it into a tangle you have to do it yourself explicitly. The ORM is OK for the usual use cases. There is only one file for routing. Tests are in their own directory. The templating language is Ruby itself so you have one less thing to learn but in theory you can shoot in your foot and write your application there, but you can always find a way to shoot yourself even in Django. There is no standard admin tool, you have to pick one yourself so you usually end up without an admin tool unless the customer pays you for that. The traditional tools for deployment were Capistrano and Mina. Maybe docker now. I made about the same amount of money from them in the past many years. I enjoyed more the weeks spent on Rails.

faraaz98 4y ago

Compared to Rails, django will feel like fastapi Imo

tommica 4y ago
What does that mean?
- devoutsalsa 4y ago
  Django is more comprehensive than FastAPI in terms of features and use cases it tries to address, so I assume they mean Rails offers more than Django. More != better.

danmaz74 4y ago

From a very long time rubyist: if you care a lot about code elegance, I think you could like ruby/rails more. If for you it's more important that there is only one correct way to do things, then probably sticking with python /Django makes sense.

chairmanwow1 4y ago
Honestly code elegance is less important than raw productivity.
- danmaz74 4y ago
  My point is that your productivity with a given tool also depends on your own preferences/cognitive style. Between Ruby/Rails and Python/Django, my assessment, even if I don't know the latter anywhere as well as the first, is that your results will depend a lot on your preferences and cognitive style.

pmontra 4y ago

I'm working with both. Django feels like a loose set of tools. That could be bad or good. You have to take more architectural decisions, every project can end up with a very different structure. You can split it into sub applications each one with its own urls file, models, controllers and migrations. Tests lay in the same directory of code. The templating language is quite constrained and inflexible. The source of truth of the database are the models and I discorage using inheritance in models or you end up with a database that no other application will ever be able to understand, humans included. The ORM feels verbose. The admin tool is good. No tools for deployment, maybe docker? In general there is a feeling of overengineering everywhere as if it was designed to keep up with every possible use case. Rails is more constrained, it's really on rails. Again, this can be both bad and good. Two projects will look the same except for those companies that adopt the services / commands / etc sub structure of the code and the ones that stick to the plain models directory, possibly lib. The source of truth of the db is the db and if you want to turn it into a tangle you have to do it yourself explicitly. The ORM is OK for the usual use cases. There is only one file for routing. Tests are in their own directory. The templating language is Ruby itself so you have one less thing to learn but in theory you can shoot in your foot and write your application there, but you can always find a way to shoot yourself even in Django. There is no standard admin tool, you have to pick one yourself so you usually end up without an admin tool unless the customer pays you for that. The traditional tools for deployment were Capistrano and Mina. Maybe docker now. I made about the same amount of money from them in the past many years. I enjoyed more the weeks spent on Rails.