Django 6.0 Beta 1 Released
Posted2 months agoActive2 months ago
djangoproject.comTechstoryHigh profile
excitedpositive
Debate
20/100
DjangoPythonWeb DevelopmentRelease
Key topics
Django
Python
Web Development
Release
The Django 6.0 beta 1 release has been announced, sparking excitement and discussion among developers about new features, such as the task framework, and potential improvements.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
N/A
Peak period
37
0-6h
Avg / period
9.3
Comment distribution56 data points
Loading chart...
Based on 56 loaded comments
Key moments
- 01Story posted
Oct 22, 2025 at 3:46 PM EDT
2 months ago
Step 01 - 02First comment
Oct 22, 2025 at 3:46 PM EDT
0s after posting
Step 02 - 03Peak activity
37 comments in 0-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 25, 2025 at 4:39 AM EDT
2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45674209Type: storyLast synced: 11/20/2025, 1:54:04 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
https://github.com/pyenv/pyenv
Simple Python version management
https://docs.astral.sh/uv/guides/install-python/
FWIW I used to be fine with just dealing with system Python, like you, but recent tools like uv make it so easy and convenient to isolate interpreters and dependencies per project that I'm just not going back.
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)
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.
But if you want to schedule a task further in the future, then a new backend will be needed for that.
But I realize there are many other usecases too that will need proper workers.
At leas that's my guess.
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?
I never considered writing my own, I just want a tool to plug in and work so I can focus on the application. I also never thought performance of this part of the stack would be a bottleneck for my use cases.
In contrast, I am happy to use Django over Flask because you can't get away from needing lots of web framework features for a nontrivial web app. The bigger framework is usually justified, especially if it's high quality like Django. But spawning tasks (for my use cases) is just an aspect of the project that can have a simple interface and it doesn't justify adopting a big framework. Time I've invested in Django (going back to 2009) is still paying off for me today, but there'd be much lower ROI on the time I'd have to put into Celery. Unless my projects really needed its complexity, but I think far fewer projects actually require that in practice than their architects tend to think.
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.
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.
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.
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
But I have a question is SpringBoot better than Django ?
It is fairly LLM friendly, so it is dead easy to whip up an admin panel for something in an evening.