Yeah I was evaluating back-end tech stack for a recent side project, most of my work these days is in TypeScript or C++, so a large part of me wanted to have types and go with a TypeScript/Node stack... but on further evaluation, both Django and Rails let you do so much on the back end with so little code, just by following their conventions and using off-the-shelf libraries, that I'm willing to trade off types in exchange for much less code to maintain (and easy Google-ability of problems).
Node is great, but I didn't come across any frameworks that rival Django or Rails in terms of maturity, and for a side project with no special requirements in terms of scalability etc., I'm not really interested in piecing together multiple libraries or writing a lot of code myself.
I actually ended up building the back-end twice lol - I was looking for the opportunity to try out GraphQL (overkill really, and it goes against what I said about keeping things simple, but I felt it was a good opportunity to try it) and ended up hitting some big performance issues with Django + Graphene – not sure how much of it was my fault vs. Python's GraphQL being slow, but in the end I rewrote the API in Rails + ruby-graphql in half a day and the performance is 5-10x faster there.
Having had the opportunity to build the same thing in them both, I'd say that Django's ORM is quite a lot better (I prefer the Django way of "update the model and the ORM will work out what migrations you need" vs Rails where you explicitly create migrations) and I prefer the Python language (simpler syntax, Ruby has so many ways to express the same thing); but Rails is probably actually quicker to work with and the quality of the Gems available for common stuff seems better than the Django equivalents.
Ultimately both Rails and Django let you get a lot done with not much code and are pretty similar conceptually – I'm impressed with both!
I completely agree about the Django ORM. I used Prisma for a couple projects and that sold the idea of "changing the model and generating the migrations" for me. Now, it feels a bit silly to explicitly define migrations. I'd love to hear some pros of the Rails/Phoenix way though.
Same, I am sure they went with that way for a reason (or perhaps it's just technically easier to implement?). I also found things like many-to-many relationships were trivial in Django, much more manual in Rails.
Node is great, but I didn't come across any frameworks that rival Django or Rails in terms of maturity, and for a side project with no special requirements in terms of scalability etc., I'm not really interested in piecing together multiple libraries or writing a lot of code myself.
I actually ended up building the back-end twice lol - I was looking for the opportunity to try out GraphQL (overkill really, and it goes against what I said about keeping things simple, but I felt it was a good opportunity to try it) and ended up hitting some big performance issues with Django + Graphene – not sure how much of it was my fault vs. Python's GraphQL being slow, but in the end I rewrote the API in Rails + ruby-graphql in half a day and the performance is 5-10x faster there.
Having had the opportunity to build the same thing in them both, I'd say that Django's ORM is quite a lot better (I prefer the Django way of "update the model and the ORM will work out what migrations you need" vs Rails where you explicitly create migrations) and I prefer the Python language (simpler syntax, Ruby has so many ways to express the same thing); but Rails is probably actually quicker to work with and the quality of the Gems available for common stuff seems better than the Django equivalents.
Ultimately both Rails and Django let you get a lot done with not much code and are pretty similar conceptually – I'm impressed with both!