Comment by meesles
5 days ago
Ruby and Rails are even better candidates. CSP, Background workers, and many other features that Django still lacks have been standard offerings for sometimes 10+ years!
5 days ago
Ruby and Rails are even better candidates. CSP, Background workers, and many other features that Django still lacks have been standard offerings for sometimes 10+ years!
Rails tries to more tightly integrate with the front-end which causes a lot of turn over the years. Django projects from 10 years ago are still upgradable in a day or two. Rails does include some nice stuff though, but I much prefer Django's code first database models than Rail's ActiveRecord.
Those Django models are a pain to work with if you have to access the database with any other tool that is not the original Django app. The only sane way to design a database managed by Django models and migrations is not using any inheritance between models or you'll end up with a number of tables, each one adding a few fields. Django ORM will join them for you but you are on your own if you ever have to write queries with some other tool.
I never had that experience.
Django does nothing special compared to the way I would design my db tables the completely manual way.
Should not be using inheritance with persistent entities anyway. OOP is not about creating taxonomies.
I do agree that Rails' asset stuff has been giant pain over the years and has not kept up well. On the other hand, some apps that adopted separate Rails APIs and a separate (for example, React) frontend have been fine. You're right though that their opinion here added more headaches that necessary!
I’d agree in that I never things like Coffeescript but I think that Rails’ frontend solution since 7.0 of Hotwire has been excellent.
Being able to sprinkle just enough JavaScript on server rended HTML works really well. That you can now use it iOS and Android apps too makes it a simpler alternative to React IMHO.
I still much prefer server rendering in a monolith than dealing with GraphQL, backend for frontend and the complexity of micro services and distributed transactions.
BTW Hotwire and Hotwire Native are also options for Django too.
CSP is literally in this release, and background workers are intentionally not part of Django because you usually want to offload tasks to other nodes so your CPU can keep serving HTTP requests.
Edit: Background tasks for light work are also included in this release.
My point was that these features that are considered new and exciting have been standard in Rails for many, many years. There are many _other_ features that Django still lacks!
I don't understand your point about the workers, since you argue it doesn't belong in Django, but then in your edit mention they have been added. To be clear I'm talking about a worker abstraction, not actually running the workers pods themselves.
You said "that Django still lacks". Django no longer lacks CSP and background tasks.
Regarding my edit, you need to differentiate between different types of jobs. Sending an email is okay to do in process. Other (mostly async) Python web frameworks have implemented this, so the Django team probably felt compelled to offer the same. Processing a user-uploaded file is much more expensive and shouldn't be done in the web process. If enough users upload files you're starving your workers for CPU.
Background workers are nearly there now, django-tasks has been partially merged into core Django in 6.0: https://github.com/RealOrangeOne/django-tasks
merb was going to do that with slices, and it seemed really promising at the time (cerca 2008), however it merged with Rails. I wish both merb and io.js had stayed independent. https://news.ycombinator.com/item?id=8884128
[dead]