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.
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.
Django 6.0 beta 1 is now available. It represents the second stage in the 6.0 release cycle and is an opportunity to try out the changes coming in Django 6.0.
You can always use pyenv to install any Python on any mainstream Linux. I only use pyenv Python to develop on any laptop or any server. My dev laptop is still Ubuntu 22.04 and I have any Python from 2.7 to 3.14 .
Yes, that's pretty typical. I think there's a general assumption if you're using older python you'll probably stick to Django LTS 5.2 from this April which still supports Python 3.10.
frio|4 months ago
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.
ranger_danger|4 months ago
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.
blef|4 months ago
michaelyin|4 months ago
[deleted]
pryelluw|4 months ago
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.
vecter|4 months ago
varispeed|4 months ago
It is fairly LLM friendly, so it is dead easy to whip up an admin panel for something in an evening.
HiPhish|4 months ago
avtar|4 months ago
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
gitaarik|4 months ago
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.
umko21|4 months ago
esafak|4 months ago
michaelyin|4 months ago
[deleted]
lpellis|4 months ago
tkcranny|4 months ago
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.
gdulli|4 months ago
ponytech|4 months ago
catlover76|4 months ago
[deleted]
manickavasagan|4 months ago
But I have a question is SpringBoot better than Django ?
BLanen|4 months ago
mervz|4 months ago
pkundi|4 months ago
rick1290|4 months ago
webology|4 months ago
hooverd|4 months ago
kavyanshkh|4 months ago
kavyanshkh|4 months ago
ranger_danger|4 months ago
davidkwast|4 months ago
https://github.com/pyenv/pyenv
Simple Python version management
gdulli|4 months ago
stackskipton|4 months ago
loloquwowndueo|4 months ago
wolf550e|4 months ago
collinmanderson|4 months ago
They only drop python versions right after LTS (which is part of why they increase the major version at that point). https://docs.djangoproject.com/en/dev/faq/install/#what-pyth...
Also Django LTS 5.2 is supported a year longer than Ubuntu 22.04. (April 2028 vs April 2027)