I sometimes think that the direction web development took is like some kind of bad dream that we will wake up from. It's unbelievable to me. The problems we faced before SPAs were things like "great we've got two forms on the same page and this widget on the top right needs to update when a message comes in from the back end… How will we ever solve this", and before anybody could come up with any good patterns google came on the scene with Angular, and ruined the entire direction of the Internet, forever.
TBH I also think that Alpine and HTMX are just as dastardly and disgusting, maybe even worse. I don't know why nobody can figure out a good way to just put in reactive components where you need them. All of the frameworks support that, Svelte seems to be the one that is the least against that, but I still don't see anybody using it that way. Front end developers, which tend to have the least business logic experience, somehow captured the entire SDLC. This is why literally all software is just completely riddled with insufferable bugs, beyond anything anyone in the 90s could have imagined.
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
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
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.
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
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.
Django powers my SaaS. I use it mainly as a data backend with its ORM, admin, and incorporate Strawberry graphql into it for the data exchange to my frontends. I wish it was better with async, though.
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.
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.
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.
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.
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.
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 agree, type annotations need work. I just use stubs and then I have some rules to set some of the more common ones to be warnings instead of errors, and then I just deal with the fact that there's gonna be some yellow squiggles.
I have the same issues in Zed and VS Code, but somehow everything works in PyCharm. Even all the double underscore nonsense in QuerySets that I've never seen work enywhere else. I don't use it very often because I mostly work from my potato of a laptop these days, but when I really just need to Get Shit Done, I sacrifice 10 browser tabs to reclaim some RAM and open PyCharm.
Pycharm does not have good type checking. It has the best type inference, but its type checking is very basic. It’s not strict, that’s why you don’t see a lot of errors. When complex types don’t much, it won’t complain.
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.
31 comments
[ 2.2 ms ] story [ 69.0 ms ] threadWho 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.?
Curious, how come Django started to make major versions instead of 1.*?
Can be the decreasing in popularity the reason to make Something to change it?
TBH I also think that Alpine and HTMX are just as dastardly and disgusting, maybe even worse. I don't know why nobody can figure out a good way to just put in reactive components where you need them. All of the frameworks support that, Svelte seems to be the one that is the least against that, but I still don't see anybody using it that way. Front end developers, which tend to have the least business logic experience, somehow captured the entire SDLC. This is why literally all software is just completely riddled with insufferable bugs, beyond anything anyone in the 90s could have imagined.
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
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.
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
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.
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.
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.
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/
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.
Sad to see so little stuff related to async though :(
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.
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 !
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.