Django forces you to declare everything. Lots of manual boilerplate. Example, you must define every bit of a model in order for it to work. Rails is the opposite. ActiveRecord will ‘just work’ with the database. You can run rails on an existing db for example if it follows what are widely used conventions such as lowercase model name is the table, foreign keys are foo_id, etc...
This is where people fear the “magic” of things like pluralization of models to table name and introspection... but it’s all just code! You can read it and look at it and understand it. No magic here. Just convenience and a smaller mental model as an end developer.
Also... resources as a first clsss citizen is the biggest reason and the reason it defeats Django for this use case. You define ‘resources’ in your routing layer instead of just routes that map to a function. This allows you represent multiple crud actions with a single controller and even nest them, all with a few lines of code. Then you get access control for free on your sub resource, knowing you’ve already passed the parent checks and have that context.
Example: /users/:id/photos/:id
In this case, my Photos controller will already know who the user is (and if they can view these photos) based on work that the parent did. It’s single responsibility principle. You can even have a top level photos resource devoid of the user context and support both cases with minimal effort.
Yes, you can do these things in Django. But it’s not designed to make these things composable and seamless. I’d argue it’s not REST-friendly. Don’t even get me started on Django Rest Framework which is a massive beast in and of itself.
You get all of that out if the box on Rails. You can stand up extremely robust and ergonomic API’s with so little code you’ll feel like your cheating.
Rails is definitely more convenient to prototype, but the magic issue is real. You never know where a variable or a function comes from by reading the source -- you'd need to run a debugger to do that (in Python you can just follow the import statements). The overall Rails architecture feels convoluted and unnecessary complicated (Railties, Engines etc). I also dislike the fact that there is no single source of truth for data in Rails. You have schema.rb, but you can't edit that directly, it is generated by running `rails db:migrate`, so one might say that migration files are a single source of truth, which is inconvenient: I need to generate a migration, then edit the migration file to add any modifications not supported by generator script and finally add accessor and validators in model file. In Django we have a model definition as a single source of truth (data model, validations). Also, once I've created (or updated) a model definition, I run `manage.py makemigrations` and all necessary migrations (which capture the current data model state + what's necessary to do to perform a database migration automatically) are created automatically. I also like the fact that in Django data integrity is enforced by default.
Though, when it comes to prototyping, I think Rails is a much more convenient option. In Rails I can launch a working CRUD app with authentication in 10 minutes, literally. In Django I have to manually create directory structure, manually specify each route mapping, create and program controllers (views), etc. Django doesn't even have a built-in authentication templates, only controllers (views), so I end up writing this boilerplate over and over again. The other thing is that the authentication requires a username and password, which feels kind of clumsy, when every other authentication relies on email and it is not very trivial to modify that (built-in admin dashboard relies on built-in authentication for example).
Example, you must define every bit of a model in order for it to work. Rails is the opposite. ActiveRecord will ‘just work’ with the database
Someone still had to create that database with those tables in it. It didn't magically pop out of the aether. Your complaint, then, is not "you must define every bit", but with where you do it, since you have to define things no matter what.
And if you have an existing database you'd like to use with Django, 'manage.py inspectdb' will reverse-engineer a set of model definitions from it.
> you must define every bit of a model in order for it to work. Rails is the opposite. ActiveRecord will ‘just work’ with the database.
If you have an existing database, sure, Rails is preferred. If you're starting from scratch, the Django definitions can create the tables for you. If you do have existing tables though, you can use inspectDB to have Django create the models for you.
I enjoy having a well-structured framework that saves me time and does not need to be spoon-fed. But I have a theory that no programmer ever died from writing an import statement.
Just wanted to anecdotally affirm whalesalad's experiences with my own. I desperately wanted to like Django more than Rails (I just really appreciate python as a language), but I find projects much quicker to build in Rails. It really is the convention-over-configuration magic that makes the difference. There's less to do in Rails to add commonly used web/crud functionality - but it's much less explicit and relies on you getting all the conventions correct. Rails is really the only framework that I've found fairly hard to learn, simply because you have to memorize the conventions to know e.g. where to pluralize and what magic helper methods will have been auto-generated.
It should be noted I've never worked on a large Django project - I suspect once a site's data structure and main functionality has been nailed down and you get a larger team involved, Python and Django's 'explicit is better than implicit' design philosophy will start to provide increases in efficiency.
I feel like you can tell a good rails developer by finding who thought it was hard to learn. There really is a lot you need to know under the magic, and if you can learn to create compatible magic in your own code the framework becomes incredibly extensible.
My Rails projects have always been the ones that felt the most done on their initial release. That extra time not typing and configuring goes into caching, validation, UX, and making nice solutions to project specific problems that fit nicely and don't become pain points as time goes on. All these things that can feel shortchanged in other projects get more of the polish they need sooner.
I've worked on a handful of large to very-large Rails apps, and I find that after a certain level of size, you're dealing with a Ruby code base that happens to have Rails as the way it is presented. Rails' implicit functions are either obvious because you use them often, or just not relevant, since you're deep in plain Ruby objects implementing your business logic.
