I love Django, and the new `tasks` framework to replace `celery` (/whatever processor you prefer) looks great.
I've only recently come back to it, and I do hope they continue to add more batteries to their "batteries included" framework over time. I was surprised just how much stuff I had to add to my little project that will require updating _outside_ the main framework, eg.:
* django-components for little template partials (I'm not sure the new partials feature is robust enough to replace this)
* django-(configurator,split-settings,pick-your-poison-here) for more robust settings management
* structlog for much better logging (feels like this should get baked into Python's stdlib...)
* debug-toolbar
* dj-database-url for parsing database URLs (should be baked in!)
* django-money
There's plenty of other deps that are less annoying/surprising (eg. Sentry, granian, Tailwind), but the set above feel like more or less like they should be baked in, and (to my mind) don't represent an inordinate amount of work to adopt.
Other than that, it's been a real pleasure coming back to it, and I'm excited for its continuation.
EDIT -- oh, and built-in static types, stubs and stubs-ext were a bit of a nightmare to get working well.
I just recently found it and it has been amazing. It logs all your requests and responses by default (but is quite configurable) as well as your SQL queries (and how many/how long they take), in an easily searchable database. It can even profile functions for you.
Makes it very to see at a glance what pages are slow for people, and why, so they can be optimized accordingly.
Love me Django and excited about this release. It’s been quite a journey through the years. I started working with it a little before 1.0 and continue to do so. Nowadays as an independent consultant which gives me the ability to really help keep Django systems up to date.
Yes, there’s some rough edges. Like updating can be tricky sometimes, and performance relating to DB queries is a skill in itself, but in general it’s a great framework to build most web software out there.
People generally don’t take the time to learn the framework and miss out on the tooling it provides. select_related for example. If I had a dollar for every project I’ve been hired to work on that didn’t use it, well, I actually do.
Also, people in general don’t seem to be able to do more than very basic SQL, so creating views is seen as a little known performance “trick”.
I assume they are referring to the default behavior of the ORM fetching all fields for a model by default, and the frequent need to use select_related/prefetch_related to group your queries into larger ones that are (usually) much faster than making many small queries for related tables.
I would really like if there was a way to integrate with non-Python ecosystems. I know this is way outside the scope of Django, but I still have to mention it. The moment you want to rely on a JavaScript library or generate some CSS you pretty much have to pull in Node and NPM because there just so much value in those ecosystems. And then you have to put up with a second ecosystem with its own build system and somehow have to magically tie those two together, adding adapters on top of adapters.
> The moment you want to rely on a JavaScript library or generate some CSS you pretty much have to pull in Node and NPM because there just so much value in those ecosystems.
Perhaps I'm missing details here but isn't that a reality with non-js web frameworks? The Phoenix docs mention esbuild and npm right off the bat:
You can just add any frontend framework and bundler you like with django. Django just serves HTML templates and you can load your JS libraries in your HTML template.
Yeah you can't use create-react-app or something. You have to do a little bit more work to set it up. But it is certainly very doable.
A task framework could be very useful, setting up celery task can get complicated very fast, especially once you have multiple servers with rolling deploys or recurring task (celery-beat).
Rails has active-job and is always something I felt was missing from Django.
Looks like Django 6 is getting an offical task system.
There’s no real world brokers or workers supported (at least built in), but still centralising around a standard interface might make things nicer than the celery tentacle monsters Django apps eventually tend to mutate into.
I'm curious, why is that? I've heard that sentence before but usually from people who want to write their own task system and end up partially implementing what celery implements just worse.
Celery is large and complex now and edge cases always show up at scale but that is usually not a reflection of the platform quality. The custom implementations I've seen are no where near what celery is capable of and can cater to so haven't seen the edge cases yet but that doesn't mean they implemented bug-free code and celery hasn't.
After asking about it, the issue always went towards a hand-wavey "performance". What is your experience on that front?
My understanding is that if you just need to return a response to the client as quickly as possible, but are ok with then processing your task directly after that, then it's still usable today.
But if you want to schedule a task further in the future, then a new backend will be needed for that.
I guess the idea is first to provide a generic interface to connect various backends to and let the community develop those. Users of Django should then be able to swap one out for another. Maybe one will emerge as a quasi-standard or maybe it will be like database backends where different backends serve different purposes.
Readit News
I've only recently come back to it, and I do hope they continue to add more batteries to their "batteries included" framework over time. I was surprised just how much stuff I had to add to my little project that will require updating _outside_ the main framework, eg.:
* django-components for little template partials (I'm not sure the new partials feature is robust enough to replace this)
* django-(configurator,split-settings,pick-your-poison-here) for more robust settings management
* structlog for much better logging (feels like this should get baked into Python's stdlib...)
* debug-toolbar
* dj-database-url for parsing database URLs (should be baked in!)
* django-money
There's plenty of other deps that are less annoying/surprising (eg. Sentry, granian, Tailwind), but the set above feel like more or less like they should be baked in, and (to my mind) don't represent an inordinate amount of work to adopt.
Other than that, it's been a real pleasure coming back to it, and I'm excited for its continuation.
EDIT -- oh, and built-in static types, stubs and stubs-ext were a bit of a nightmare to get working well.
I just recently found it and it has been amazing. It logs all your requests and responses by default (but is quite configurable) as well as your SQL queries (and how many/how long they take), in an easily searchable database. It can even profile functions for you.
Makes it very to see at a glance what pages are slow for people, and why, so they can be optimized accordingly.
Dead Comment
Yes, there’s some rough edges. Like updating can be tricky sometimes, and performance relating to DB queries is a skill in itself, but in general it’s a great framework to build most web software out there.
Also, people in general don’t seem to be able to do more than very basic SQL, so creating views is seen as a little known performance “trick”.
In general, people who don’t read the manual.
It is fairly LLM friendly, so it is dead easy to whip up an admin panel for something in an evening.
Perhaps I'm missing details here but isn't that a reality with non-js web frameworks? The Phoenix docs mention esbuild and npm right off the bat:
https://hexdocs.pm/phoenix/asset_management.html
Laravel expects node, npm, and vite at the very least:
https://laravel.com/docs/12.x/vite
Yeah you can't use create-react-app or something. You have to do a little bit more work to set it up. But it is certainly very doable.
Dead Comment
There’s no real world brokers or workers supported (at least built in), but still centralising around a standard interface might make things nicer than the celery tentacle monsters Django apps eventually tend to mutate into.
Celery is large and complex now and edge cases always show up at scale but that is usually not a reflection of the platform quality. The custom implementations I've seen are no where near what celery is capable of and can cater to so haven't seen the edge cases yet but that doesn't mean they implemented bug-free code and celery hasn't.
After asking about it, the issue always went towards a hand-wavey "performance". What is your experience on that front?
But if you want to schedule a task further in the future, then a new backend will be needed for that.
At leas that's my guess.
Dead Comment
But I have a question is SpringBoot better than Django ?