If anyone is curious, I've been maintaining a Docker Compose based Django + Celery + Postgres + Redis + esbuild + Tailwind starter app for years and just updated it for Django 6.0 at https://github.com/nickjj/docker-django-example.
The only thing I haven't done is pre-configure the new CSP settings because I want to let that marinate a bit before putting it in as a default.
One thing Django has going for it is that the "batteries included" nature of it is perfect for AI code generation.
You can get a working site with the usual featuers (admin panel, logins, forgot reset/password flow, etc) with minimal code thanks to the richness of the ecosystem, and because of the minimal code it's relatively easy for the AI to keep iterating on it since it's small enough to be understandable in context.
On top of this, it's understandable to humans when reviewing generated code. There's no 2000-line FooBarAdmin component where bugs could be located. And if you're having it generate HTML templates, you can see exactly what backend model property/method was used without needing to follow the indirection through backends and prop drilling.
And when you do create backends and React components, you can have a known-good ground truth in your Django admin that's independent from that frontend. This is incredibly useful in practice - if a certain e.g. malformed input triggers a catastrophic frontend crash, you have an entirely separate admin system you can use to play with the data, without needing to trace to find the exact cause of the frontend crash, or dropping into direct database access.
(My one gripe with Django, which is more with the broader Python ecosystem, is that if the community had leaned into the gevent programming model (no explicit async, all socket calls are monkey-patched to yield, you just write sync code), there would be no need for async versions/ports of every Django library function, no confusion in the library ecosystem, and instant upgrades of every Django library in existence to an async world. gevent is a thing of beauty and that's a hill I'll die on.)
Now I've been dabbling outside of Django, I realised some of those things come from bits people don't think about much:
INSTALLED_APPS and other bits in the settings provide a central registration point, from there the system where a project is made up of apps is enabled.
Each app, has it's own migrations, models, templates and static files.
This enables the whole ecosystem of parts that's easy to add, and makes it easy to toggle things (e.g. enabling the django-debug-toolbar only on your dev and local instance).
In the outside world of Flask, Fast API etc - things hang together much more loosely and it means the integration just isn't as complete.
This manifests itself in 1,000 little papercuts that make things take longer.
I have tried both Django and Rails for this, and honestly, very surprisingly, Rails did much better, at least with Claude Code. This is for a rewrite of an old .net application. Claude nailed it almost perfectly with Rails, but struggled with Django. YMMV.
Ruby and Rails are even better candidates. CSP, Background workers, and many other features that Django still lacks have been standard offerings for sometimes 10+ years!
And because Django is so popular in open source projects and it has been around for such a long time, there's tons of code out there for AI to train on.
Claude is insanely good with Django and React. I think the best thing that happened to Python was type hints because it lets LLMs reason Python code easier.
why would you need batteries included? the ai can code most integrations (from scratch, if you want, so if you need something slightly off the beaten path it's easy
I worked at an org which has a ‘modern’ NodeJS+React codebase and an ancient legacy Django app on Python 2.7 which is nearing 15 years old.
I was worried that the old codebase would be a pain to work on. It was the complete other way around. The Django app was a complete joy to work with and I literally had so much fun tidying it up and working with it that I’ll be sad when they finally retire it in favor of the new new Go/React rewrite.
Django has been one of the biggest reasons why web development has been so enjoyable to me. Whenever I switched to something else, I just felt too spoiled by everything that Django gives you. So I always ended up back with Django, and have no regrets at all specializing deep down that path.
Django was my first big freelance project, and still feels tremendously cozy to use. I've done some goofy things with it and it's always served me really well. Thank you Django
Using Django for almost 15 years, almost exclusively, for both business and personal projects. Have tried a lot of other frameworks, nothing clicks so good with me.
My only (small) complain with this release would be that they included the task framework but didn't include a task backend and worker. I'd prefer to wait a bit and include everything in the next version.
Good job, template partials looks like a nice improvement !
That being said, the current state of type annotations is a pain: django-stubs works on mypy but with a plugin (and mypy is slow as hell), django-types is a fork a django-stubs that works on pyright but is usually out of sync and pylance ships its owned stubs forked from django-types.
My biggest wish for next Django release would be that they finally ship type annotations themselves where it is possible. I don't need the crazy inheritance parts or the crazy stringly typed parts to be have proper type annotations, but just some simple stuff like HttpRequest, HttpResponse, View, Model, etc would help a LOT !
I see a lot of people in here talking about the "batteries included" aspect of Django, as if that's where it really shines. those batteries are definitely helpful, but the biggest benefit, by far, is the absolute best ORM in existence.
If somebody were to reproduce the Django ORM, with full native asynchronous support, it would change Python forever. I know there are people who come from SQLAlchemy and swear by it. As somebody who has used both I can tell you, at least when working with a small team on enterprise software, the ORM blows SQLAlchemy out of the water, in terms of being able to produce quality software, quickly.
For anyone new out there thinking about using FastAPI... don't. You'll find 1 million people on the Internet happy to tell you that it's terrific, and 90% of these people have not built real software. The performance gains are lost, by double when you attempt to build real real software with it. I've worked with it in three different apps, and in all three cases it was used because the front end team insisted that all we needed was REST. In all three cases I have seen page load times that are slower than the 90s, 3 to 10 seconds or more before everything is done on the page. It's actually unbelievable to me that that is the direction a lot of Python backend development has gone in, relegating all the important logic, and, in a lot of cases, security, to frontend niceties.
I really love django and everything around it, but I would also like to write a webapp in Java.
Getting django + rest_framework up and running and actually be productive takes me max 10 minutes, trying to do the same with spring boot I am a week in and I had to open the jakarta specs to understand the magic.
Java honestly just does not have this. By the time java collectively decided that being able to spend your time writing your actual product instead of fucking with config shit forever, the age of the monolithic SSR templated backend app were gone. So now most modern things like helidon focus on being microservicey like go, or they have very soft template rendering offerings and don't really do batteries included.
I feel your pain, I myself am working on a react frontend + spring boot backend and fiddling with it to integrate with spring session, security, etc properly was a HUGE pain because neither world knows anything at all about each other. If I did it from scratch I'd just "rails new myapp" and be done already.
I'm not sure why people aren't saying Spring Boot, but Spring Boot. Yeah it has heaps of other batteries included, and it doesn't have a built-in admin, but it gives you pretty decent stuff out of the box
Django is awesome, but I wish there was an easy way to use modern web frameworks with it.
A lot of times it's either through Nextjs/Nuxtjs + Django as an API or complex bundling process which requires a file where you register bundle versions/manifests then another build process which embeds them into template
I used Django for a project a couple of years ago. Of course, there's a lot to learn. But generally I found that everything makes sense and I was able to build a moderately complex site with user accounts within a reasonable time. Work took me in different directions, but if a project came up I'd use it again, no problem.
Last year I taught myself Next.js for a project. Everyone would say that's a modern framework, with a modern website. I already know React, I'm quite familiar with prisma.js. Learning and using it was (and is, because now I have to maintain the project) painful, confusing, and full of footguns. I wanted to host on Cloudflare but half the stuff doesn't work so I'm forced into Vercel. Takes ages to understand how images work, how server side works, and so on, and those things are still confusing to me. Constantly I ran into tricky problem about getting data to a client side component, or server side, because some UI library wasn't server side or something like that. Even getting the two fonts I'd chosen into a client side component took me several hours! And I still felt like the solution I came up with was hacky and fighting against the framework.
I regret learning the "modern" framework. I don't regret learning Django. Don't let fancy marketing fool you into using a bad tool, or drive you away from a good one.
I trust them more precisely because they are not wasting resources making slick start-upy marketing fluff that make it difficult to find the actual information I am looking for.
Amazing. If this means no more management of Celery workers, then I am so happy! So nice to have this directly built _into_ Django, especially for very simple task scheduling.
Do you guys find Django includes enough batteries? Why or why not?
I find myself using Cookiecutter Django [^1] more often than not, better auth, a bunch of boilerplate configs, S3 and email setups if you want, and other stuff rather than have to jiggle with "Django infra" myself
Flask is my go-to, but I've had great fun with Rust recently.
Django is the best thing in the world for writing Django apps. (No, I'm not trying to be funny there. If what you're doing looks like something Django would solve, it's fantastic.) But most of the things I do aren't Django apps, and ones you get off its happy path, you can be in for a world of hurt. Oh, you use SQLAlchemy everywhere else, and you'd like to use it in your Django app so that you can have one set of models and re-use the service logic you've built? Hah, too bad! Or you need your REST API output to look a very specific way? Have fun with that! Your auth model doesn't look just like Django's? Hope your LLM is good at smoothing that over!
The good side is that it's an opinionated framework that does a lot of research on your behalf and makes some great choices. The bad side is that you better agree with its opinions or you're in for a bad time.
This would make an interesting poll. I think that's possible here? Maybe with some karma threshold, I don't seem to be able to make one.
We use flask and go at work. I've been micro-framework or roll-my-own-framework most of my career. Go is new for me though, and it's grown on me enough that it's what I prefer for new web-facing projects even for little personal things.
I"m almost entirely dotnet these days, with a smattering of Go here and there.
I work in ops though, so I'm not building consumer-facing products but mostly IT glue code and internal tooling (mostly Go), dashboards, business report generators, gluing SaaS together, etc. (mostly dotnet/C#).
I started using Django before the official 1.0 release and used it almost exclusively for years on web projects.
Lately I prefer to mix my own tooling and a couple major packages in for backends (FastAPI, SQLAchemy) that are still heavily inspired by patterns I picked up while using Django. I end up with a little more boilerplate, but I also end up with a little more stylistic flexibility.
[+] [-] nickjj|3 months ago|reply
If anyone is curious, I've been maintaining a Docker Compose based Django + Celery + Postgres + Redis + esbuild + Tailwind starter app for years and just updated it for Django 6.0 at https://github.com/nickjj/docker-django-example.
The only thing I haven't done is pre-configure the new CSP settings because I want to let that marinate a bit before putting it in as a default.
[+] [-] stevex|3 months ago|reply
You can get a working site with the usual featuers (admin panel, logins, forgot reset/password flow, etc) with minimal code thanks to the richness of the ecosystem, and because of the minimal code it's relatively easy for the AI to keep iterating on it since it's small enough to be understandable in context.
[+] [-] btown|3 months ago|reply
And when you do create backends and React components, you can have a known-good ground truth in your Django admin that's independent from that frontend. This is incredibly useful in practice - if a certain e.g. malformed input triggers a catastrophic frontend crash, you have an entirely separate admin system you can use to play with the data, without needing to trace to find the exact cause of the frontend crash, or dropping into direct database access.
(My one gripe with Django, which is more with the broader Python ecosystem, is that if the community had leaned into the gevent programming model (no explicit async, all socket calls are monkey-patched to yield, you just write sync code), there would be no need for async versions/ports of every Django library function, no confusion in the library ecosystem, and instant upgrades of every Django library in existence to an async world. gevent is a thing of beauty and that's a hill I'll die on.)
[+] [-] stuaxo|3 months ago|reply
INSTALLED_APPS and other bits in the settings provide a central registration point, from there the system where a project is made up of apps is enabled.
Each app, has it's own migrations, models, templates and static files.
This enables the whole ecosystem of parts that's easy to add, and makes it easy to toggle things (e.g. enabling the django-debug-toolbar only on your dev and local instance).
In the outside world of Flask, Fast API etc - things hang together much more loosely and it means the integration just isn't as complete.
This manifests itself in 1,000 little papercuts that make things take longer.
[+] [-] rufugee|3 months ago|reply
[+] [-] BowBun|3 months ago|reply
[+] [-] bigfatkitten|3 months ago|reply
[+] [-] giancarlostoro|3 months ago|reply
[+] [-] theflyinghorse|3 months ago|reply
[+] [-] throwawaymaths|3 months ago|reply
[+] [-] varun_ch|3 months ago|reply
I was worried that the old codebase would be a pain to work on. It was the complete other way around. The Django app was a complete joy to work with and I literally had so much fun tidying it up and working with it that I’ll be sad when they finally retire it in favor of the new new Go/React rewrite.
[+] [-] Genego|3 months ago|reply
[+] [-] sroerick|3 months ago|reply
[+] [-] nadermx|3 months ago|reply
[+] [-] spapas82|3 months ago|reply
My only (small) complain with this release would be that they included the task framework but didn't include a task backend and worker. I'd prefer to wait a bit and include everything in the next version.
[+] [-] wg0|3 months ago|reply
[+] [-] ducdetronquito|3 months ago|reply
That being said, the current state of type annotations is a pain: django-stubs works on mypy but with a plugin (and mypy is slow as hell), django-types is a fork a django-stubs that works on pyright but is usually out of sync and pylance ships its owned stubs forked from django-types.
My biggest wish for next Django release would be that they finally ship type annotations themselves where it is possible. I don't need the crazy inheritance parts or the crazy stringly typed parts to be have proper type annotations, but just some simple stuff like HttpRequest, HttpResponse, View, Model, etc would help a LOT !
[+] [-] gonational|3 months ago|reply
If somebody were to reproduce the Django ORM, with full native asynchronous support, it would change Python forever. I know there are people who come from SQLAlchemy and swear by it. As somebody who has used both I can tell you, at least when working with a small team on enterprise software, the ORM blows SQLAlchemy out of the water, in terms of being able to produce quality software, quickly.
For anyone new out there thinking about using FastAPI... don't. You'll find 1 million people on the Internet happy to tell you that it's terrific, and 90% of these people have not built real software. The performance gains are lost, by double when you attempt to build real real software with it. I've worked with it in three different apps, and in all three cases it was used because the front end team insisted that all we needed was REST. In all three cases I have seen page load times that are slower than the 90s, 3 to 10 seconds or more before everything is done on the page. It's actually unbelievable to me that that is the direction a lot of Python backend development has gone in, relegating all the important logic, and, in a lot of cases, security, to frontend niceties.
[+] [-] sparklingmango|3 months ago|reply
[+] [-] Arbortheus|3 months ago|reply
[+] [-] gnulinux996|3 months ago|reply
I really love django and everything around it, but I would also like to write a webapp in Java.
Getting django + rest_framework up and running and actually be productive takes me max 10 minutes, trying to do the same with spring boot I am a week in and I had to open the jakarta specs to understand the magic.
[+] [-] frikk|3 months ago|reply
[+] [-] atomicnumber3|3 months ago|reply
I feel your pain, I myself am working on a react frontend + spring boot backend and fiddling with it to integrate with spring session, security, etc properly was a HUGE pain because neither world knows anything at all about each other. If I did it from scratch I'd just "rails new myapp" and be done already.
[+] [-] sdwvit|3 months ago|reply
[+] [-] frio|3 months ago|reply
[+] [-] willahmad|3 months ago|reply
A lot of times it's either through Nextjs/Nuxtjs + Django as an API or complex bundling process which requires a file where you register bundle versions/manifests then another build process which embeds them into template
both are so complex
[+] [-] sergiotapia|3 months ago|reply
The site makes the project feel extremely dated, which of course I have no idea how true that is, I've never used Django! Just my 2c from an outsider.
I compare it to Phoenix and Rails. (again, talking PURELY marketing here dudes!)
https://www.phoenixframework.org/
https://rubyonrails.org/
[+] [-] esperent|3 months ago|reply
Last year I taught myself Next.js for a project. Everyone would say that's a modern framework, with a modern website. I already know React, I'm quite familiar with prisma.js. Learning and using it was (and is, because now I have to maintain the project) painful, confusing, and full of footguns. I wanted to host on Cloudflare but half the stuff doesn't work so I'm forced into Vercel. Takes ages to understand how images work, how server side works, and so on, and those things are still confusing to me. Constantly I ran into tricky problem about getting data to a client side component, or server side, because some UI library wasn't server side or something like that. Even getting the two fonts I'd chosen into a client side component took me several hours! And I still felt like the solution I came up with was hacky and fighting against the framework.
I regret learning the "modern" framework. I don't regret learning Django. Don't let fancy marketing fool you into using a bad tool, or drive you away from a good one.
Don't judge a web framework by it's website.
[+] [-] abenga|3 months ago|reply
[+] [-] cl42|3 months ago|reply
Amazing. If this means no more management of Celery workers, then I am so happy! So nice to have this directly built _into_ Django, especially for very simple task scheduling.
[+] [-] personjerry|3 months ago|reply
I find myself using Cookiecutter Django [^1] more often than not, better auth, a bunch of boilerplate configs, S3 and email setups if you want, and other stuff rather than have to jiggle with "Django infra" myself
[^1]: https://github.com/cookiecutter/cookiecutter-django
[+] [-] novoreorx|2 months ago|reply
[+] [-] echelon|3 months ago|reply
Who uses Django, Rails, or similar full-featured frameworks?
Who uses micro-frameworks like Flask?
Who uses enterprise Java, Jetty, Dot Net, etc.?
Who uses an entirely Javascript stack?
Who uses a non-traditional language that has become more web-servicey, like Go, Rust, or Swift?
Who uses something so wildly untraditional that it's barely mentioned? OkCupid using C++, etc.?
Who uses an entirely custom framework (in any language)?
Would really love to see a break down of who is using what, how people feel about their tech stack, etc.?
[+] [-] kstrauser|3 months ago|reply
Django is the best thing in the world for writing Django apps. (No, I'm not trying to be funny there. If what you're doing looks like something Django would solve, it's fantastic.) But most of the things I do aren't Django apps, and ones you get off its happy path, you can be in for a world of hurt. Oh, you use SQLAlchemy everywhere else, and you'd like to use it in your Django app so that you can have one set of models and re-use the service logic you've built? Hah, too bad! Or you need your REST API output to look a very specific way? Have fun with that! Your auth model doesn't look just like Django's? Hope your LLM is good at smoothing that over!
The good side is that it's an opinionated framework that does a lot of research on your behalf and makes some great choices. The bad side is that you better agree with its opinions or you're in for a bad time.
[+] [-] hecanjog|3 months ago|reply
We use flask and go at work. I've been micro-framework or roll-my-own-framework most of my career. Go is new for me though, and it's grown on me enough that it's what I prefer for new web-facing projects even for little personal things.
[+] [-] alberth|3 months ago|reply
Eg, this post has ~50 (though only posted an hour ago)
Rails 8 had ~550
https://news.ycombinator.com/item?id=41766515
[+] [-] yoavm|3 months ago|reply
[+] [-] thewebguyd|3 months ago|reply
I work in ops though, so I'm not building consumer-facing products but mostly IT glue code and internal tooling (mostly Go), dashboards, business report generators, gluing SaaS together, etc. (mostly dotnet/C#).
[+] [-] tcdent|3 months ago|reply
Lately I prefer to mix my own tooling and a couple major packages in for backends (FastAPI, SQLAchemy) that are still heavily inspired by patterns I picked up while using Django. I end up with a little more boilerplate, but I also end up with a little more stylistic flexibility.
[+] [-] codr7|3 months ago|reply
Also used Flask and similar libraries for back ends.
Did one project in Rails, which was a pretty bad experience in comparison, and killed any motivation to look into Django.
Also did plenty of Spring in Java professionally, unfortunately.
[+] [-] ChrisArchitect|3 months ago|reply