Django 6.0 beta 1 released | Hacker News Reader

Django 6.0 beta 1 released

djangoproject.com

114 pointswebology56 comments

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.

In addition to the debug-toolbar, I'd really like people to know about https://github.com/jazzband/django-silk (no affiliation)

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.

This is neat, thanks :)

Silk is so dang amazing I deploy it to devel and staging at work. It helps me so quickly drill down at bad ORM or SQL performance issues.

Absolutely! Just wish half the filters weren't broken... if I try to show only "POST" requests or only things from X seconds ago, it just always shows nothing... several other fields aren't working either.

I'm curious to see how you successfully got working well the types as I'm lost in the nightmare for a few days.

In `pyproject.toml`:

    "django-stubs>=5.2",
    "django-stubs-ext>=5.2.2",

In `settings.py`, add:

    import django_stubs_ext

    django_stubs_ext.monkeypatch()

With that, it seems _mostly_ OK, though I had to toggle off some of basedpyright's typechecking.

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.

What're some DB query performance issues you've run across in the past and how did you resolve them?

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.

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”.

In general, people who don’t read the manual.

FYI you can avoid the manual sprinkling of select_related somewhat with https://pypi.org/project/django-auto-prefetch/, which avoids the lowest hanging N+1 loops automatically. Definitely not a cure all but it helps.

Yes, aware of this option. Thanks for posting it!

Customers who like django-auto-prefetch may also like django-zeal: https://pypi.org/project/django-zeal/

Ah yes. That’s the one thing I need to teach everyone when they’re new to Django. I was wondering if there were other quirks to the ORM beyond avoiding N+1 queries.

I love Django - it's so boring and just works.

It is fairly LLM friendly, so it is dead easy to whip up an admin panel for something in an evening.

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.

Like for what?

DRF and Django Ninja do this? For magically tying the ecosystems, I recommend generating client side http libraries from the OpenAPI schema.

> 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:

https://hexdocs.pm/phoenix/asset_management.html

Laravel expects node, npm, and vite at the very least:

https://laravel.com/docs/12.x/vite

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 don´t understand how you could use this new tasks system in production if there is no real workers when it's released? Are there any 3rd party yet?

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.

At leas that's my guess.

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 think the bigger use case is being able to (backoff) retry failing API calls to 3rd party services. AFAIUI the new tasks package doesnt offer this in v1 which is a deal breaker for my project, at least.

For me I think it works well as is because my use case is sending several different emails after POST'ing to a view, which, there is no need to make the user wait for in my case, as they don't care about the status of the mail delivery.

But I realize there are many other usecases too that will need proper workers.

Right, I'd never touch celery, but RQ is simple and has never let me down.

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 experience is that Celery is fragile. It loses the connection with RabbitMQ sometimes and it needs a restart to recover. I never had those problems with Rails and Sidekiq + Redis.

I'll choose the small, simple, reliable tool over the larger framework every time, if I can get away with having the smaller feature set. I'd go out of my way to make the simpler tool work if I could, to keep the overall cognitive load and complexity of the project down.

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.

Wow !! Finally a new version is released !! . I love Django because it have Simple Syntax,Support large Scale application and modern .

But I have a question is SpringBoot better than Django ?

How is django performance these days? I remember the average latencies(100ms+) for even simple things being a non-starter for me.

I noticed this in development mode but performance improved substantially in production

Django is great. With complete async support, it would be my de-facto backend framework of choice.

whats your defacto now?

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.

Django tasks!? Waow.

cool! will just wait for the rc or release then.

cool! will wait for rc or full release then ig.

Incompatible with the default Ubuntu 22.04 LTS python version, just FYI (uses 3.10 whereas the minimum is now 3.12).

Is this handled by uv or do you need to use deadsnakes ppa?

If anything, you'd need the opposite, as deadsnakes is old versions (OP needs a new version).

deadsnakes has 3.13.8, 3.14.0 and 3.15-a1 for 22.04: https://launchpad.net/~deadsnakes/+archive/ubuntu/ppa?field....

Oh interesting, I didn't realize they started including newer versions. I guess that makes the name a misnomer then...

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.

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)

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 .

https://github.com/pyenv/pyenv

Simple Python version management

Wow I had no idea about that, thanks!

Better yet, uv:

https://docs.astral.sh/uv/guides/install-python/

Building Python from source is trivial, I wouldn't let the distro dictate what I can and can't use for such an important part of the stack.

Ops here, using System Python is always asking for trouble, just put Django into a container and call it a day.

What kind of trouble? That's all I've ever used for the last 15 years of my professional Django work and never had any issues...

Anything involving Distro updating. There is no reason not to use containers except Docker Build scary!

Incompatibility with Python version in current LTS Ubuntu sounds like an issue to me.

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.

If you need Python 3.12 you should update to Ubuntu 24.04 if you want to stick with distro packages.

Reply on news.ycombinator.com