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.
I should probably write a blog post.
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).
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.
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.
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.
Ruby - Rails
PHP - Laravel
all nice choices
Elixir - Phoenix
I wish there was a complete Clojure - ???
Elixir itself is an excellent language that leveraged the strengths of the Erlang VM, and Phoenix is like a massively improved, blazing fast and reliable version of Rails.
It will be the logical successor to Rails. It already is.
That said, I use a good mix of Elixir+Phoenix and old-school cron launched Python utility scripts, and that works nicely. Anything that's difficult (probably because I am still a newb) in Elixir I can easily do out of band with a Python script.
But your point about difficult to hire experienced people is the reason for my reply. This is the mentality that is ruining IT and development. Yes, having someone with hands on experience in all of your tools is nice - a rare luxury in fact. But it's really not necessary. I would be quite happy to have someone that has willingly built something in Rails, Django, and Nodejs with an "Oh I can learn that" attitude. Especially if you come from a modern MVC framework, Phoenix itself is easy. Elixir is the part that requires some real effort, imo.
I personally find that Laravel is less heavy than Django which is way less heavy than RoR. I would never use RoR for small projects.
btw: what do you use for the database access? Slick, Quill, Doobie, ScalikeJDBC, Anorm, Squeryl, jOOQ, Relate, Activate or something else? There seem to be gazillions of sql libraries for scala (although the big three and most relevant are probably Slick, Quill and Doobie).
And what do you use for Authorization? Something custom build? If I look at Laravel there are quite a few maintained authorization libs with ~1000 stars on youtube (even more if we count unmaintained), for play there is not really much (deadbolt, play4j and t2v/play2-auth, I don't count Silhouette since the lib is mainly about authentication).
Rhetorical question by the way... just food for thought. There is a balance. I happen to love the convention rails imposes and the “magic” it offers. That being said, there isn’t anything about it that I consider wizardry or don’t understand. It’s just ruby.
Are you not talking about Java here? ;)
Clearer code makes it easier to reason and hence easier debugging. Correct me if I am wrong.
Also, it really depends on person to person on how they write the code. Django does not mean big boilerplate nor does Rails.
My main question was on performance. How do they stack up next to each other? Python3 with Django is really working well these days. You can also check out the performance improvement on Instagram because of it. https://thenewstack.io/instagram-makes-smooth-move-python-3/