Django 6.0 released
29 points by jefftriplett
29 points by jefftriplett
I'm excited. I always love a major version update. The release notes seem really straight forward and luckily in my code base I only had one actionable code change.
At work we only bump between LTS so I'm looking forward to 2027 Q1 ;)
I will likely give partial templates a try to see how much it improves the devx when using htmx and co.
How is the experience of working only with LTS ? Is the upgrade painful between LTS ? If not painful, why not upgrading more often to no every release?
The last couple times I used Django at work we did this as well. Honestly, it's not too bad. There were a couple of big releases that required pretty substantial changes to some settings (the one that comes to mind is the DATABASES dict), but for the most part there's very few breaking changes and the Django maintainers do an excellent job of documenting them and providing step-by-step migration guides.
So, it's been sad to see Python's async journey in which they adopted the "colored" split from javascript. The Python web ecosystem felt hard-hit, as there popped up an entirely separate ecosystem of async (ASGI) vs sync (WSGI) frameworks and libraries. Django had to make a separate code-path for async templates and so on.
Question I have is: for Django or for people into similar tools in the ecosystem, how annoying has this split been? Is my perception above accurate? How much extra work did Django need to do to support both worlds? How does one choose a framework in the Python ecosystem these days?
I haven't really been annoyed at all honestly. It's nice to be able to have an async view if what that view is doing is calling other remote APIs. For the database, we use the gevent'ed backend so the MAIN thing we'd want async has been async for years.
My personal opinion is that people feel like they need async without really measuring and knowing that it is, indeed, better/faster/easier for their particular usage patterns. That they are missing out on some huge performance improvement that they, in all honestly, will likely not experience.
How much extra work did Django need to do to support both worlds?
I don't pay attention too too closely, but there was a forum thread that's relevant: Is DEP009 (“async-capable Django”) still relevant?.
In it they touch on how much work the split between worlds is and they even link to an interesting Async-SIG thread with Guido chiming in: How can async support dispatch between sync and async variants of the same code?.
Last I remember, people were playing around with the idea of code generation based on the works of psycopg. That blog post goes into details but the tldr is to write the async version of your project and use code generation to produce a sync version, and publish them separately.
How does one choose a framework in the Python ecosystem these days?
Personally, all of the above seems kind of excessive to me. I've worked on Django applications for a while and there are some times I wish I could write asynchronous code, but for the majority of use cases it's just not that painful to toss something into a celery task. If I were writing a simple API I would probably reach for FastAPI, and for anything bigger than that I would use synchronous Django as well as I could.