Probably the wrong time or place but I am also on the market literally as of yesterday so if anyone is looking for an experienced Django guy, I'm your man! oldspiceap@gmail.com
manage.py makemigrations myapp --empty --name add_some_view
operations=[migrations.RunSQL("Create View some_view AS ....", "DROP VIEW IF EXISTS...."]
class SomeView(models.Model):
class Meta:
db_table = 'some_view'
managed = False
manage.py makemigrations myapp --name add_some_view_modelIt will be interesting to see how the tasks framework develops and expands. I am sad to see the great Django-Q2 lumped in with the awful Celery though.
There are bugs and issues, but because so many people are using it, you’re rarely the first to stumble upon a problem. We processed double-digit millions of messages daily with Celery + RabbitMQ without major obstacles. Regardless of what people say, it should be your first go-to.
I often prefer designing around explicit queues and building workers/dispatchers. One queuing system I miss is the old Google App Engine one - you set up the queue, the URL it calls with the payload (in your own app), the rate it should use, and that's it.
Yeah, I mentioned Celery due to its popularity, no other reason ;)
I also use Kafka on other tech stacks but that's another level completely and use case.
— https://steve.dignam.xyz/2023/05/20/many-problems-with-celer...
> The problems with (Python’s) Celery:
— https://docs.hatchet.run/blog/problems-with-celery
> Dramatiq motivation:
— https://dramatiq.io/motivation.html
Here are some alternatives:
Dramatiq: https://github.com/Bogdanp/dramatiq
https://news.ycombinator.com/item?id=45797228
https://python-absurd-client.readthedocs.io/en/latest/quicks...
And debugging is a pain in the ass. Most places I’ve been that have it, I’ve tried to sell them on adding Flower to give better insight and everyone thinks that’s a very good idea but there isn’t time because we need to debug these inscrutable Celery issues.
- your function arguments aren't serializable - your side effects (e.g. database writes) aren't idempotent - discovering what backpressure is and that you need it - losing queued tasks during deployment / non-compatible code changes
There's also some stuff particular to celery's runtime model that makes it incredibly prone to memory leaks and other fun stuff.
Honestly, it's a great education.
What does idempotent mean in this context, or did you mean atomic/rollback on error?
I'm confused because how could a database write be idempotent in Django? Maybe if it introduced a version on each entity and used that for crdt on writes? But that'd be a significant performance impact, as it couldn't just be a single write anymore, instead they'd have to do it via multiple round trips
Task queues are like email. It's what everyone is used to so people ask for more of it, but it's not actually good/the right tool.
Fundamentally I think the entire idea behind celery and django-q is mostly misguided. People normally actually need a good scheduler and a bring-your-own queue in tables that you poll. I wrote Urd to cover my use cases and it's been rock solid.
* https://pypi.org/project/fast_html/
* https://fastht.ml/ (different to above, I think)
* https://github.com/volfpeter/fasthx
Probably others. I strongly prefer this to templating, but I find it makes dyed in the wool Django people squirm.
A jinja/django template has an implicit context but for nested functions you really have to pass that context down through every function call.
It inevitably ends up just a big dict blob.
You get some typing support in an IDE but nothing really for function parameters.
Maybe I am doing wrong?
The downside is I find them hard to read.
I think the template approach isn't quite right and yet neither is the functional approach.
At the end of the day these are a type of tree structure; I think we could conjure a new mechanism that gets the best of most/both worlds.
To be honest my main problem with templates is they have to be one per file. In principle there's no difference between naming a new file and naming a function, but in practice it just sucks. It's a higher barrier so people are less likely to write smaller components, and refactoring support completely sucks. Even renaming a template is a massive pain whereas renaming a function with decent LSP support is easy.
JSX hits that perfect balance between readability while still being regular functions. Maybe something is possible with the new 3.13 template strings?
Everyone just busts out "React" for every small thing, but few commit to actually learning this pretty complicated technology.
The last two recent Cloudflare outages were because of React.
>Jinja2 can offer performance improvements, particularly when it comes to speed.
https://docs.djangoproject.com/en/6.0/topics/performance/#al...
https://adamj.eu/tech/2025/12/03/django-whats-new-6.0/#rende...
What I would like is a way to cut down the sprawl of urls and views.
The use case is mainly driven by htmx where you will have lots of these partials and the view code renders them as individual responses.
I'm using Unpoly and I just render the whole page and let Unpoly swap the content according to the target selectors, so no need for this. Not much difference in perf if you dont generate gigantic pages with heavy header/footer.
The way you can render just a named partial from both the render() shortcut and the include tag is nice too:
https://docs.djangoproject.com/en/6.0/ref/templates/language...
There is something very appeasing in just pulling Django and have all the basics covered. It's nice to have options when needed though.
Also, good to see first class support for Tasks, among a lot of other niceties!
https://guides.rubyonrails.org/layouts_and_rendering.html#pa...
https://github.com/RealOrangeOne/django-tasks
Is that correct?
Has there been discussion about adopting/embedding django-tasks into Django 6.x?
I am not roasting it or anything, go Django, but just an observation.
Not just the Framework -> Core migration itself, but the power to make breaking changes went to their heads, and they started quickly tearing up everything only to change their minds again, such as a short-lived "project.json" syntax.
Django is exactly the technology I'd pick if I wasn't already super familiar with the .NET stack. It's got the "batteries included" feel without the chaotic confusion of a million ways to do things. It doesn't have the breaking changes churn that happens elsewhere too.
Nothing wrong with that. One had to start somewhere.
I get remarkably good and correct LLM output for Django projects compared to what I get in project with more fast moving and frequently API breaking frameworks.
Edit, it's about 37%, and python-only. https://arxiv.org/pdf/2310.06770v3
These guidelines are relevant here:
Eschew flamebait. Avoid generic tangents. Omit internet tropes.
Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.
Please don't complain about tangential annoyances—e.g. ... name collisions ... . They're too common to be interesting.
It makes me sad when a secondary meaning, which does not even overcome the main meaning in usage, becomes an obstacle for the normal use of a word. It's like seeing a rainbow as a sexualized symbol not fit for children, because it also happens to be used by LGBTQ+ community. (BTW, since you're a Brit: did people stop using the word "fag" to refer to a cigarette?)
> did people stop using the word "fag" to refer to a cigarette?
Yes, seems so. I've not heard that in at least a decade
Slightly absurdist non-sensical humour I’ll admit, but none the less, a joke :-)