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.
Switching to uv ~6-7 months ago was so worth it. It took like 3 seconds to repackage this project thanks to uv, that's building and locking every dependency with Docker too.
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.
I just verified. You can install Python 2.7 on an up to date Windows install as well as an up to date Linux install. Python 2.7 hasn't received security updates (or really any updates) in years, but that does not mean it can't still work on an up to date OS.
Yeah, it's been 5 years (almost 6) since python 2.7 stopped receiving security updates, but it does still run on modern OS's.
Looking at the list, I'm actually kind of surprised there aren't more CVEs for python 2.7, but if you're only running it locally or on an intranet I could see letting it ride.
Did it a couple of times. Not something you can do with your eyes closed, but not even close to the nightmare of upgrading a JS application or upgrading a rails app.
Nothing like a full rewrite. I migrated multiple projects, but while there is a significant amount of work involved its a tiny fraction of what a full rewrite would require.
I remember having great fun in QuickBASIC. And my son enjoys Scratch.
Django code is much more fun to work with than Node, but I can't imagine developing something competitive in it in 2025 to what I'm developing in Node. Node is a pain in the butt, but at the end of the day, competitiveness is about what you deliver to the user, not how much fun you have along the way.
* I think the most fundamental problems are developer-base/libraries and being able to use the same code client-side and server-side.
* Django was also written around the concept of views and templates and similar, rather than client-side web apps, and the structure reflects that.
* While it supports async and web sockets, those aren't as deep in the DNA as for most Node (or even aiohttp) apps.
* Everything I do now is reactive. That's just a better way to work than compiling a page with templates.
I won't even mention mobile. But how you add that is a big difference too.
It's very battery-included, but many of the batteries (e.g. server-side templating language) are 2005-era nickel cadmium rather than 2025-era lithium ion.
I would love to see a modern Node framework as pleasant to work with, thought-out, engineered, documented, supported, designed, etc. as well as Django, but we're nowhere close to there yet.
You spell out a lot of examples, but all of them are purely technical. What is it that you can deliver to the user using Node that you cannot deliver using Django? This is a genuine question.
Man, the only true part is the async/web socket part (and it's most because of python and not django itself) ... you can do a lot, and by a lot I mean almost 99% of websites/apps out there, with django and it's 2005-era nickel cadmium features
The lithium-ion battery analogy seems fitting: When we're not careful about sourcing those modern batteries from a trustworthy supply-chain, they tend to explode and injure the user.
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.
It can be similar to WordPress plugins, but as problematic as WordPress plugins are, they went a lot farther in terms of ecosystem. While stored in the database, the WordPress plugins do the equivalent of INSTALLED_APPS, calling the code to register them.
Someone tried to make an ecosystem of Django apps, called Pinax, and it was pretty nice, but didn't pick up that much market share.
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.
Ive been pleasantly surprised by claudes ability to handle a real-world rails codebase thats 5-10 years old in various spots. We dont do a lot of ruby magic / metaprogramming, and arent particularly 'railsy' in our patterns, but its had no issues figuring things out (even the light metaprogramming we _do_ use).
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.
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!
Rails tries to more tightly integrate with the front-end which causes a lot of turn over the years. Django projects from 10 years ago are still upgradable in a day or two. Rails does include some nice stuff though, but I much prefer Django's code first database models than Rail's ActiveRecord.
Those Django models are a pain to work with if you have to access the database with any other tool that is not the original Django app. The only sane way to design a database managed by Django models and migrations is not using any inheritance between models or you'll end up with a number of tables, each one adding a few fields. Django ORM will join them for you but you are on your own if you ever have to write queries with some other tool.
I do agree that Rails' asset stuff has been giant pain over the years and has not kept up well. On the other hand, some apps that adopted separate Rails APIs and a separate (for example, React) frontend have been fine. You're right though that their opinion here added more headaches that necessary!
I’d agree in that I never things like Coffeescript but I think that Rails’ frontend solution since 7.0 of Hotwire has been excellent.
Being able to sprinkle just enough JavaScript on server rended HTML works really well. That you can now use it iOS and Android apps too makes it a simpler alternative to React IMHO.
I still much prefer server rendering in a monolith than dealing with GraphQL, backend for frontend and the complexity of micro services and distributed transactions.
BTW Hotwire and Hotwire Native are also options for Django too.
CSP is literally in this release, and background workers are intentionally not part of Django because you usually want to offload tasks to other nodes so your CPU can keep serving HTTP requests.
Edit: Background tasks for light work are also included in this release.
My point was that these features that are considered new and exciting have been standard in Rails for many, many years. There are many _other_ features that Django still lacks!
I don't understand your point about the workers, since you argue it doesn't belong in Django, but then in your edit mention they have been added. To be clear I'm talking about a worker abstraction, not actually running the workers pods themselves.
You said "that Django still lacks". Django no longer lacks CSP and background tasks.
Regarding my edit, you need to differentiate between different types of jobs. Sending an email is okay to do in process. Other (mostly async) Python web frameworks have implemented this, so the Django team probably felt compelled to offer the same.
Processing a user-uploaded file is much more expensive and shouldn't be done in the web process. If enough users upload files you're starving your workers for CPU.
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 think the logic can be applied to humans as well as AI:
Sure, the AI _can_ code integrations, but it now has to maintain them, and might be tempted to modify them when it doesn't need to (leaky abstractions), adding cognitive load (in LLM parlance: "context pollution") and leading to worse results.
Batteries-included = AI and humans write less code, get more "headspace"/"free context" to focus on what "really matters".
As a very very heavy LLM user, I also notice that projects tend to be much easier for LLMs (and humans alike) to work on when they use opinionated well-established frameworks.
Nonetheless, I'm positive in a couple of years we'll have found a way for LLMs to be equally good, if not better, with other frameworks. I think we'll find mechanisms to have LLMs learn libraries and projects on the fly much better. I can imagine crazy scenarios where LLMs train smaller LLMs on project parts or libraries so they don't get context pollution but also don't need a full-retraining (or incredibly pricey inference). I can also think of a system in line with Anthropic's view of skills, where LLMs very intelligently switch their knowledge on or off. The technology isn't there yet, but we're moving FAST!
> As a very very heavy LLM user, I also notice that projects tend to be much easier for LLMs (and humans alike) to work on when they use opinionated well-established frameworks.
i have the exact opposite experience. its far better to have llms start from scratch than use batteries that are just slightly the wrong shape... the llm will run circles and hallucinate nonexistent solutions.
that said, i have had a lot of success having llms write opinionated (my opinions) packages that are shaped in the way that llms like (very little indirection, breadcrumbs to follow for code paths etc), and then have the llm write its own documentation.
I don't even particularly care for Django, but darned if I'd want to reimplement on my own any of the great many problems they've thoroughly solved. It's so widely used that any weird little corner case you can think of has already been addressed. No way I'd start over on that.
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.
Have you tried Ruby on Rails. That's my experience with Rails. Everytime I've tried something else (for web dev), I just felt too spoiled with Ruby & Rails and went back. This includes Django and Phoenix (Elixir).
Edit: The only thing that Rails lacks is a decent Admin UI included as part of Rails. I know that there are some external gems that can be used, yet that's something that should be part of the framework in my opinion.
Even before you get to the lacking Admin UI, the first thing Rails asks me to do is implement authentication. Coming from a true batteries-included framework like Django that feels like a complete non-starter.
I use Django a lot and it's great, but even I have to admit that Ruby on Rails is better. It's just that I don't really do a lot of Ruby, so I ended up on the familiar tech stack, and also finding other developers to join a project is much easier with Python.
I feel very comfortable with Django on the frontend, what are you missing there? I usually use Tailwind or Bulma, with HTMX and AlpineJs. I feel like the experience can be very much React like, even if you leave out HTMX. The frontend game of Django really changed about 2 years ago (at least for me).
Laravel's Blade templates are just absolutely phenomenal. The partial rendering, the integration with Livewire, the first class component paradigm. It's just far beyond stock Django / Jinja at this point and delivers some serious dev experience performance boosts.
Glad to hear that works for you. But nothing of what you are mentioning is part of Django, nor an official package,etc.
And I’m not going to get into the details of whether that stack would work for non backend developers, developers working on medium/large projects and/or medium/large teams. That’s a separate and unrelated discussion.
But compare what Django brings you (Stone Age templating system and that’s it) to what Laravel provides out of the box (or via official packages) like assets bundling, live reloading, an amazing and modern template system with proper “component like” partials or even if you need them, the “big guns” such as Inertia or Livewire. More or less the same is true for Rails with the Hotwire stuff.
There’s absolutely no point of comparison here. Even if that works for you, Django is not even in the same league.
It is still a great backend framework though, which was my point.
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
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, by far.
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 Lowe alchemy out of the water, in terms of being able to produce quality software, quickly.
For anyone out there thinking about using FastAPI... don't. You'll find 1 million people on the Internet happy to tell you that it's the best thing ever, and 90% of these people have not built real software. Just like somebody else in here mentioned that they had a role working in Django as well as some react/go and that Django was a pleasure, etc. Everyone flocks to whatever is new and shiny and trusts all the hype, but Django has been a high quality, stable, yet evolving, framework through all of it, and will continue to be.
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.
No one has mentioned it: mobile! Mobile apps became a thing, and there was a strong argument to have one common backend for your web app and your iOS app and your Android app. Plus the mobile UX (especially with iOS apps at the time) was such a gamechanger that there was a natural shift to replicate it in the browser.
That said, even though I still build SPAs at work, but I can't wait for the day that I get to build something big with Django & htmx.
I'm not in web anymore but, to me, it seemed easier to visualize richly linked data in Angular than having a Django template render it. Once you have the mindset of making your website into an app, you are tempted to move navigation to the app too. That way your app can keep delivering its core user function without the interruption of a page load.
In retrospect it was slightly hubristic, as in reality you sometimes have to force reload SPA's, and if you're integrating on top of legacy systems that you just link to, you're not really avoiding the bad UX of a jarring page load. But I do find it elegant to separate presentation from data.
Because the web was made to render documents, but users want apps. CSS in part is so confusing because its original incarnations pulled heavily from traditional print media layout terms.
Everything since then was an attempt to leverage JS to turn documents into applications. Why? Ask any user.
Internet was slower in both latency and throughput is one reason. The other is general tendency to separate things into smaller pieces. Faster feedback to user is the third.
Consider a typical form with 10 fields in django. You define the schema on a backend, some validation here and there, a db lookup and form-level rules (if this field is entered, make the other field optional).
This works very welly in django, but you only get the result once you fill all the fields and press enter, at which point the whole thing gets sent through model-tempalte-controller thing and the resulting page is returned over a faulty slow connection. It also hits the database which is not great because SSD is not invented yet and you can't keep the whole thing in RAM or overprovision everything 100x. Containers, docker and devops are not invented yet as well.
So you try to add some javascript into the template and now you have two sets of validators written in two different languages (transpilers are not invented yet) and the frontend part is the ugly one because declarative frameworks like react dont exist, so you add ad-hoc stuff into the template. Eventually everyone gets annoyed by this and invents nice things, so you move the part that was template rendering+form completely to the FE and let two different teams maintain it and communicate through the corporate bureaucracy that tracks the source of truth for validation rules outside of the code.
At some point you notice that people name fields in the json schema in a way that is not consistent and forget the names, so you put even bigger boundary between them with a formal API contract and independent party to approve it (I kid you not, there are places where the API between FE and BE teams is reviewed by a fancy titled person that doesn't deal with either team outside of this occasion).
Eventually you figure out that running the frontend logic on the backend is easier (it's doing the same model-view-whatever patter anyway) than other way around and remove the fence making all the bureaucratic overhead disappear in one clap.
Then somebody finds an RCE in server components.
You are here.
Add: if you want to feel the WEB before SPA, here is a nice example: https://formulieren.amsterdam.nl/TriplEforms/DirectRegelen/f... (bonus points for opening two different forms from site:formulieren.amsterdam.nl in different tabs and clicking through them in parallel)
You still end up separating frontend and backend in full js codebases, but it's not as explicit and can lead to wacky/confusing/unpredictable behavior if you get it wrong. I've never found a perfect solution to the frontend/backend boundary but I've found a mix of declarative container type libraries (pydantic on backend, TypeBox on frontend) with some code generation is a good solution.
I work in a place where it's proper to wait for a month, get the openapi spec thrown over the fence from the backend team and generate my typescript RPC out of it. The upside is I don't get paged at 4 in the morning if the thing gets into a bad mood and starts doing increased 5xx at increased rate.
I'm 32, but I noticed I started making similar mistakes around 28 or so. Occasionally I write out words which are completely wrong, but sound similar.
It's as if one part of the brain is doing the thinking, and another one is "listening" to it and transcribing/typing it out, making mistakes.
For a little while I was a bit worried, but I then realized nothing else had changed, so I've just gotten used to it and like to jokingly say "I've become so fast at thinking that even I can't keep up!"
I suspect that as I got more vocabulary (and more languages) and started to actually speak the language more, I remember the "sound" of the word where I used to remember the spelling before. Like "it's" and "its" wasn't a problem before, but now I catch it somewhere in the text. At least I consistently write more than 50% of the articles nowdays. Languages are weird.
While I was writing the reply, I considered giving the absolutely exact same explanation, which I agree with, down to the example you gave.
Two examples in portuguese that always trip me up, and absolutely never used to before are (i) "voz" (voice) and "vós" (you); and (ii) "trás" (back) and "traz" (bring).
Aside from the usual separation of tech stacks for different teams, the big thing for me is lack of any sort of type hinting or safety in templates at least in the big frameworks such as Django, Rails etc. I would much rather work with a separate build process that utilizes typescript than deal with the errors that come out of incorrectly reading formless data and making typos within templates.
Is that really such a big problem? These days you can type annotate what you pass to the rendering function for templates and then you know what type you have in the template. If you have a minimum of testing, heck even manual testing will do, I don't think too many mistakes make it to staging, let alone production. I would think it well worth to be able to opt out of the JS ecosystem.
I had similar thoughts, but how does one use an RDBMS without making use of FKs? Do they put all in one huuuge table, that has all the columns and is super sparse? Or some other fever dream of bad design?
And is even worse, this is stuff that I have seen in ERPs (I integrate with several).
One of them, not even use "date"/"decimal" types and all is mostly strings, there is not views or anything else, and the tables AND fields are called "F0001..".
In my experience it's boiled down to the type of data you're working with. Building nested, tree-like structures and then submitting that structure to the back-end as one request is more easily done via the front-end than a bunch of back-and-forth requests followed up by a "commit" request.
edit: I suppose this is different concern than a true SPA, but as another sibling comment points out, its just a matter of time before routing makes its way into the front-end as well.
For me, yes, it is. I make an app for myself, and I thought about making it a server-rendered app like you suggested. But it's just so much better in my opinion to do everything on the client side because it means that every interaction has zero latency, regardless of the quality of my internet (which is often bad).
- Strict team separation (frontend versus backend)
- Moving all state-managament out of the backend and onto the frontend, in a supposedly easier to manage system
- Page refreshes are indeed jarring to users and more prone to leading to sudden context losses
- Desktop applications did not behave like web apps: they are "SPA"s in their own sense, without jarring
refreshes or code that gets "yanked" out of execution. Since the OS has been increasingly abstracted under the browser, and the average computer user has moved more and more towards web apps[1], it stands to reason that the behavior of web apps should become more like that of desktop apps (i.e. "SPA"s)[2]
(Not saying I agree with these, merely pointing them out)
[1] These things are not entirely independent. It can be argued that the same powers that be (big corps) that pushed SPAs onto users are also pushing the "browser as OS" concept.
[2] I know you can get desktop-like behavior from non-SPAs, but it is definitely not as easy to do it or at least to _learn it_ now.
My actual opinion: I think it's a little bit of everything, with a big part of it coming from the fact that the web was the easiest way to build something that you could share with people effortlessly. Sharing desktop apps wasn't particularly easy (different targets, java was never truly run everywhere, etc.), but to share a webapp app you just put it online very quickly and have someone else point their browser to a URL -- often all they'll do is click a link! And in general it is definitely easier to build an SPA (from the frontender's perspective) than something else.
This creates a chain:
If I can create and share easily
-> I am motivated to do things easily
-> I learn the specific technology that is easiest
-> the market is flooded with people who know this technology better than everything else
-> the market must now hire from this pool to get the cheapest workers (or those who cost less to acquire due to quicker hiring processes)
-> new devs know that they need to learn this technology to get hired
-> the cycle continues
So, TL;DR: Much lower barrier to entry + quick feedback loops
P.S (and on topic): I am an extremely satisfied django developer, and very very very rarely touch frontend. Django is A-M-A-Z-I-N-G.
These days with 90% of SPAs being broken piles of browser standard breaking stuff, I find a page refresh or page load to be a soothing experience. They are like checkpoints in the process of using a website. Points to which I can go back using my browser's back button, and I can trust, that my browser keeps track of them.
In contrast, when I see an SPA, I need to worry about the whole site going to shit, because I blocked some third-party unwanted script, and then I need to fear not being able to go back properly, and having to re-do everything. Now that is a jarring experience.
I feel you. It's definitely a tradeoff. SPAs do tend to be buggier but I can't deny that, when done right, they also tend to be better.
Unfortunately, there's _more_ people, building _more_ stuff, so there's _more_ terrible stuff out there. The amount of new apps (and new developers, especially ones with quite limited skills) is immense compared to something like ten years ago. This means that there's just more room for things to be poorly-built.
Not being able to new tab to a new instance of the app is terrible. Even super complex SPAs like Facebook let me for the most part right click new tab to create a new instance while preserving the old one.
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 !
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
Django is a modern web framework. It simply doesn't follow the hype around JS SPAs. However, if you really want to, you can of course still render static content + serve a JS framework like Vue to the client, and then have dynamic widgets rendered on the client side.
If you want to build an SPA anyway, then Django is not the right framework to start with though.
Probably one, whose basic idea is to make an SPA. Django has all the tools for making a multi page website/application, which you are then not using. There is probably a framework that is based on the idea of making an SPA and that doesn't include the other stuff.
That's just for the HTML content though. What if you want to add some non-trivial Javascript or generated CSS? Or maybe you want to integrate a frontend tool like Storybook[0] even if your HTML is rendered server-side? Maybe add some tests for your frontend code? There is much more between raw hand-rolled HTML/CSS/JS and a full-blown SPA.
At my day job we use Django with HTMX and Alpine, but we also generate the custom CSS from Pico[1] and use JinjaX[2] to define server-side components which we then render in Storybook. We use Vue as our bundler to compile the JS and CSS as well as to run Storybook. The project has to live in both the Python ecosystem and the Node.js ecosystem.
Even with just HTMX and Alpine you might want to compile a custom version of those with certain plugins, or you might want to load them as libraries in your own scripts.
Yes the API process is very complex and then you have to have a team with proficiency in two parallel sets of web technologies -- python vs javascript. That said, the fact that you can go that route means that Django can be a good pick for early-stage projects where you don't need a frontend framework, because there's the optionality to add it later if your project really requires it.
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
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.
You will have to keep Celery for the foreseeable future. The current implementation is just a stub which provides a unified interface for some future backends.
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
Ruby is a far better language from a design standpoint and Rails is a better framework in both design and maturity. Sadly, Ruby is a domain-specific language for web backends these days. Most new startups pick Python and TS for their versatility.
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.
It's amazing, that django docs look and feel exactly the same the did in 0.9x. Damn kids with their JS bullshit have to change the whole site between v1 and v2 and then again when v3 happens. Links rot, API index is hidden and instead of text you get a dump of TS interfaces with zero comments.
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.
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.
In a company that uses a traditional web framework like Django to actually build the frontend and backend, not just as only for implementing the APIs, I would even consider doing parts of frontend work again, making everything responsive and so on. That's what I do for a not-yet-startup project.
As fully-featured as possible, because as much as I like building stuff, I don’t give a shit about coding stuff that has been figured out since the 90’s. Another question is whether semantics and operations get bloated or affect development speed in a framework but I don’t think it’s the case with the Django.
I agree that Go is a good choice for web services. I disagree that it's the only thing Go is good at. DevOps tooling and CLI tools immediately spring to mind.
I target 5.10.1 mostly. This is for a project I started in the late 90's. It uses CGI::Application, which is less a framework and more a method lookup table converter of queries (although I built a path info convertor on top of that). It's still maintained, although before Covid, it was my livelihood.
About a quarter of a million lines of code, excluding the libraries I pull in. I'm mostly self-taught, they wouldn't even let me get a minor in Comp Sci, since I didn't have the math background (Needed Calculus, I completeled Algebra 2 in hs). Boneheaded Uni.
Raku: Second-system effect poster boy. Sensationally dysfunctional community. I think Pugs is what was actually really incredible and Audrey is probably one of the most intelligent people in... the World? Up for contention, but top 10.
Congrats to the Django team!
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.
Thanks. Just went to bookmark it, but pinboard says I already did so in December of 2023.
All of Nick's repos are top notch and I high recommend them and reference them from my materials as well.
Nick, thank you for sharing so much in the open.
Hah, I used this a few years back on a project. Great work!
Very cool and can tell you keep up with it just with your addition of uv!
Thanks.
Switching to uv ~6-7 months ago was so worth it. It took like 3 seconds to repackage this project thanks to uv, that's building and locking every dependency with Docker too.
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.
Do a guerilla port of it to modern Django.
Why would they retire it? If it ain't broke...
It’s very likely that project is a security nightmare. Just an OS old enough to support 2.7 would be problematic.
I just verified. You can install Python 2.7 on an up to date Windows install as well as an up to date Linux install. Python 2.7 hasn't received security updates (or really any updates) in years, but that does not mean it can't still work on an up to date OS.
The latest 2.7 seems to have a lot of CVEs (did not verify that manually though)
https://www.cvedetails.com/version-list/10210/18230/10/Pytho...
IIRC some commercial distros maintain patches for 2.7 but then you're paying for being 15 years behind the future.
Yeah, it's been 5 years (almost 6) since python 2.7 stopped receiving security updates, but it does still run on modern OS's.
Looking at the list, I'm actually kind of surprised there aren't more CVEs for python 2.7, but if you're only running it locally or on an intranet I could see letting it ride.
There are variants of Python 2.7 that are supported
wouldn't it be faster/safer to upgrade to latest django/python rather than rewrite it in React/Go?
Python 2 to Python 3 in a Django codebase ... may be a full rewrite anyway.
Its fine, I ported quite a few Django libraries to python 3 at the time just because I wanted to use them.
2to3 gets you pretty far and theres not much in the rest.
Did it a couple of times. Not something you can do with your eyes closed, but not even close to the nightmare of upgrading a JS application or upgrading a rails app.
Many people migrated Django projects from 2 -> 3. Certainly something that takes effort, but hardly a rewrite.
Nothing like a full rewrite. I migrated multiple projects, but while there is a significant amount of work involved its a tiny fraction of what a full rewrite would require.
"Fun" isn't the same thing as "functional."
I remember having great fun in QuickBASIC. And my son enjoys Scratch.
Django code is much more fun to work with than Node, but I can't imagine developing something competitive in it in 2025 to what I'm developing in Node. Node is a pain in the butt, but at the end of the day, competitiveness is about what you deliver to the user, not how much fun you have along the way.
* I think the most fundamental problems are developer-base/libraries and being able to use the same code client-side and server-side.
* Django was also written around the concept of views and templates and similar, rather than client-side web apps, and the structure reflects that.
* While it supports async and web sockets, those aren't as deep in the DNA as for most Node (or even aiohttp) apps.
* Everything I do now is reactive. That's just a better way to work than compiling a page with templates.
I won't even mention mobile. But how you add that is a big difference too.
It's very battery-included, but many of the batteries (e.g. server-side templating language) are 2005-era nickel cadmium rather than 2025-era lithium ion.
I would love to see a modern Node framework as pleasant to work with, thought-out, engineered, documented, supported, designed, etc. as well as Django, but we're nowhere close to there yet.
You spell out a lot of examples, but all of them are purely technical. What is it that you can deliver to the user using Node that you cannot deliver using Django? This is a genuine question.
You must not be very imaginative.
Plenty of Django businesses making tens of millions. Some in the billions.
I know a solopreneur making around $2m a year and all he uses is Django
Man, the only true part is the async/web socket part (and it's most because of python and not django itself) ... you can do a lot, and by a lot I mean almost 99% of websites/apps out there, with django and it's 2005-era nickel cadmium features
The lithium-ion battery analogy seems fitting: When we're not careful about sourcing those modern batteries from a trustworthy supply-chain, they tend to explode and injure the user.
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.)
I prefer gevent over explicit async so I'll die on that hill with you. The cooperative model adopted by Python async is... bad.
One meeting with the original gevent author explains why it has not achieved broad acceptability.
It is rather sad for humanity that good ideas through-out time have been lost thanks to neurodiversity / social-acceptability constraints.
I just do not use Python async. Mostly I do not need it. If I do I would rather use something else.
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.
Yes, 100%, you end up with a massive main.py file instantiating everything and trying to couple and register stuff.
It can be similar to WordPress plugins, but as problematic as WordPress plugins are, they went a lot farther in terms of ecosystem. While stored in the database, the WordPress plugins do the equivalent of INSTALLED_APPS, calling the code to register them.
Someone tried to make an ecosystem of Django apps, called Pinax, and it was pretty nice, but didn't pick up that much market share.
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.
Ive been pleasantly surprised by claudes ability to handle a real-world rails codebase thats 5-10 years old in various spots. We dont do a lot of ruby magic / metaprogramming, and arent particularly 'railsy' in our patterns, but its had no issues figuring things out (even the light metaprogramming we _do_ use).
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.
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!
Rails tries to more tightly integrate with the front-end which causes a lot of turn over the years. Django projects from 10 years ago are still upgradable in a day or two. Rails does include some nice stuff though, but I much prefer Django's code first database models than Rail's ActiveRecord.
Those Django models are a pain to work with if you have to access the database with any other tool that is not the original Django app. The only sane way to design a database managed by Django models and migrations is not using any inheritance between models or you'll end up with a number of tables, each one adding a few fields. Django ORM will join them for you but you are on your own if you ever have to write queries with some other tool.
Should not be using inheritance with persistent entities anyway. OOP is not about creating taxonomies.
I never had that experience.
Django does nothing special compared to the way I would design my db tables the completely manual way.
I do agree that Rails' asset stuff has been giant pain over the years and has not kept up well. On the other hand, some apps that adopted separate Rails APIs and a separate (for example, React) frontend have been fine. You're right though that their opinion here added more headaches that necessary!
I’d agree in that I never things like Coffeescript but I think that Rails’ frontend solution since 7.0 of Hotwire has been excellent.
Being able to sprinkle just enough JavaScript on server rended HTML works really well. That you can now use it iOS and Android apps too makes it a simpler alternative to React IMHO.
I still much prefer server rendering in a monolith than dealing with GraphQL, backend for frontend and the complexity of micro services and distributed transactions.
BTW Hotwire and Hotwire Native are also options for Django too.
CSP is literally in this release, and background workers are intentionally not part of Django because you usually want to offload tasks to other nodes so your CPU can keep serving HTTP requests.
Edit: Background tasks for light work are also included in this release.
My point was that these features that are considered new and exciting have been standard in Rails for many, many years. There are many _other_ features that Django still lacks!
I don't understand your point about the workers, since you argue it doesn't belong in Django, but then in your edit mention they have been added. To be clear I'm talking about a worker abstraction, not actually running the workers pods themselves.
You said "that Django still lacks". Django no longer lacks CSP and background tasks.
Regarding my edit, you need to differentiate between different types of jobs. Sending an email is okay to do in process. Other (mostly async) Python web frameworks have implemented this, so the Django team probably felt compelled to offer the same. Processing a user-uploaded file is much more expensive and shouldn't be done in the web process. If enough users upload files you're starving your workers for CPU.
Background workers are nearly there now, django-tasks has been partially merged into core Django in 6.0: https://github.com/RealOrangeOne/django-tasks
merb was going to do that with slices, and it seemed really promising at the time (cerca 2008), however it merged with Rails. I wish both merb and io.js had stayed independent. https://news.ycombinator.com/item?id=408011 https://news.ycombinator.com/item?id=8884128
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.
This is generally true of all of these frameworks: Django, Laravel, rails, phoenix
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 think the logic can be applied to humans as well as AI:
Sure, the AI _can_ code integrations, but it now has to maintain them, and might be tempted to modify them when it doesn't need to (leaky abstractions), adding cognitive load (in LLM parlance: "context pollution") and leading to worse results.
Batteries-included = AI and humans write less code, get more "headspace"/"free context" to focus on what "really matters".
As a very very heavy LLM user, I also notice that projects tend to be much easier for LLMs (and humans alike) to work on when they use opinionated well-established frameworks.
Nonetheless, I'm positive in a couple of years we'll have found a way for LLMs to be equally good, if not better, with other frameworks. I think we'll find mechanisms to have LLMs learn libraries and projects on the fly much better. I can imagine crazy scenarios where LLMs train smaller LLMs on project parts or libraries so they don't get context pollution but also don't need a full-retraining (or incredibly pricey inference). I can also think of a system in line with Anthropic's view of skills, where LLMs very intelligently switch their knowledge on or off. The technology isn't there yet, but we're moving FAST!
Love this era!!
> As a very very heavy LLM user, I also notice that projects tend to be much easier for LLMs (and humans alike) to work on when they use opinionated well-established frameworks.
i have the exact opposite experience. its far better to have llms start from scratch than use batteries that are just slightly the wrong shape... the llm will run circles and hallucinate nonexistent solutions.
that said, i have had a lot of success having llms write opinionated (my opinions) packages that are shaped in the way that llms like (very little indirection, breadcrumbs to follow for code paths etc), and then have the llm write its own documentation.
Maybe if they could learn how to switch their intelligence on, that would help more?
What’s more likely to have a major security problem – Django’s authentication system or something custom an LLM rolled?
I don't even particularly care for Django, but darned if I'd want to reimplement on my own any of the great many problems they've thoroughly solved. It's so widely used that any weird little corner case you can think of has already been addressed. No way I'd start over on that.
Because then every app is a special snowflake.
At some point you'll need to understand things to fix it, and if it's laid out in a standard way you'll get further, quicker.
Its literally the opposite.
Why would you generate sloppy version of core systems that must be included by default in every project.
It makes absolutely zero sense to generate auth/email sending/bg tasks integration/etc
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.
Have you tried Ruby on Rails. That's my experience with Rails. Everytime I've tried something else (for web dev), I just felt too spoiled with Ruby & Rails and went back. This includes Django and Phoenix (Elixir).
Edit: The only thing that Rails lacks is a decent Admin UI included as part of Rails. I know that there are some external gems that can be used, yet that's something that should be part of the framework in my opinion.
Even before you get to the lacking Admin UI, the first thing Rails asks me to do is implement authentication. Coming from a true batteries-included framework like Django that feels like a complete non-starter.
Rails now provides an authentication generator that creates a super terse but fully customisable auth capability. Here’s an example: https://insidertrades.directory/built-with-rails/google-sign...
I use Django a lot and it's great, but even I have to admit that Ruby on Rails is better. It's just that I don't really do a lot of Ruby, so I ended up on the familiar tech stack, and also finding other developers to join a project is much easier with Python.
That’s true as long as you are only talking about the backend.
Frontend wise, Django is in the Stone Age.
Look at Laravel or rails if you want a really complete full stack solution.
I feel very comfortable with Django on the frontend, what are you missing there? I usually use Tailwind or Bulma, with HTMX and AlpineJs. I feel like the experience can be very much React like, even if you leave out HTMX. The frontend game of Django really changed about 2 years ago (at least for me).
Laravel's Blade templates are just absolutely phenomenal. The partial rendering, the integration with Livewire, the first class component paradigm. It's just far beyond stock Django / Jinja at this point and delivers some serious dev experience performance boosts.
https://laravel.com/docs/12.x/blade
Haters are downvoting you probably because of mentioning anything PHP related.
But what you say is true. Blade is amazing.
Glad to hear that works for you. But nothing of what you are mentioning is part of Django, nor an official package,etc.
And I’m not going to get into the details of whether that stack would work for non backend developers, developers working on medium/large projects and/or medium/large teams. That’s a separate and unrelated discussion.
But compare what Django brings you (Stone Age templating system and that’s it) to what Laravel provides out of the box (or via official packages) like assets bundling, live reloading, an amazing and modern template system with proper “component like” partials or even if you need them, the “big guns” such as Inertia or Livewire. More or less the same is true for Rails with the Hotwire stuff.
There’s absolutely no point of comparison here. Even if that works for you, Django is not even in the same league.
It is still a great backend framework though, which was my point.
Nitpicking...
Never understood the appeal. I started with the web before there were any frameworks, in PHP, and Django was always very meh.
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
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, by far.
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 Lowe alchemy out of the water, in terms of being able to produce quality software, quickly.
For anyone out there thinking about using FastAPI... don't. You'll find 1 million people on the Internet happy to tell you that it's the best thing ever, and 90% of these people have not built real software. Just like somebody else in here mentioned that they had a role working in Django as well as some react/go and that Django was a pleasure, etc. Everyone flocks to whatever is new and shiny and trusts all the hype, but Django has been a high quality, stable, yet evolving, framework through all of it, and will continue to be.
Django's batteries included setup makes it a no brainer for almost any project big or small. Kudos to the team and contributers
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.
Are they planning to include this? It seems like the kind of demarcation point the framework would avoid crossing into.
I think they should. Not sure if they will.
However Adam Johnson mentioned django-tasks as the reference implementation that may be included in Django here https://adamj.eu/tech/2025/12/03/django-whats-new-6.0/.
Perfect should not be the enemy of good, after all Django is the framework for perfectionists with deadlines ;)
Can someone remind me how we ended up in the SPA era and why exactly? Was it about not seeing the loading spinner? Or there were more reasons to it?
No one has mentioned it: mobile! Mobile apps became a thing, and there was a strong argument to have one common backend for your web app and your iOS app and your Android app. Plus the mobile UX (especially with iOS apps at the time) was such a gamechanger that there was a natural shift to replicate it in the browser.
That said, even though I still build SPAs at work, but I can't wait for the day that I get to build something big with Django & htmx.
This. An SPA has some chance of being repackaged as an app without major surgery, a Django app really doesn’t. So you have to maintain it separately.
PWAs/Webviews/etc are not really practical options.
I'm not in web anymore but, to me, it seemed easier to visualize richly linked data in Angular than having a Django template render it. Once you have the mindset of making your website into an app, you are tempted to move navigation to the app too. That way your app can keep delivering its core user function without the interruption of a page load.
In retrospect it was slightly hubristic, as in reality you sometimes have to force reload SPA's, and if you're integrating on top of legacy systems that you just link to, you're not really avoiding the bad UX of a jarring page load. But I do find it elegant to separate presentation from data.
Because the web was made to render documents, but users want apps. CSS in part is so confusing because its original incarnations pulled heavily from traditional print media layout terms.
Everything since then was an attempt to leverage JS to turn documents into applications. Why? Ask any user.
I don't think blaming this mess on users makes much sense.
Smartphones on the other hand...
Uh, I certainly don't want apps. The Web is a terrible app platform, native is so much better in every case. Just documents, please.
Written from a web app
>Or there were more reasons to it?
Internet was slower in both latency and throughput is one reason. The other is general tendency to separate things into smaller pieces. Faster feedback to user is the third.
Consider a typical form with 10 fields in django. You define the schema on a backend, some validation here and there, a db lookup and form-level rules (if this field is entered, make the other field optional).
This works very welly in django, but you only get the result once you fill all the fields and press enter, at which point the whole thing gets sent through model-tempalte-controller thing and the resulting page is returned over a faulty slow connection. It also hits the database which is not great because SSD is not invented yet and you can't keep the whole thing in RAM or overprovision everything 100x. Containers, docker and devops are not invented yet as well.
So you try to add some javascript into the template and now you have two sets of validators written in two different languages (transpilers are not invented yet) and the frontend part is the ugly one because declarative frameworks like react dont exist, so you add ad-hoc stuff into the template. Eventually everyone gets annoyed by this and invents nice things, so you move the part that was template rendering+form completely to the FE and let two different teams maintain it and communicate through the corporate bureaucracy that tracks the source of truth for validation rules outside of the code.
At some point you notice that people name fields in the json schema in a way that is not consistent and forget the names, so you put even bigger boundary between them with a formal API contract and independent party to approve it (I kid you not, there are places where the API between FE and BE teams is reviewed by a fancy titled person that doesn't deal with either team outside of this occasion).
Eventually you figure out that running the frontend logic on the backend is easier (it's doing the same model-view-whatever patter anyway) than other way around and remove the fence making all the bureaucratic overhead disappear in one clap.
Then somebody finds an RCE in server components.
You are here.
Add: if you want to feel the WEB before SPA, here is a nice example: https://formulieren.amsterdam.nl/TriplEforms/DirectRegelen/f... (bonus points for opening two different forms from site:formulieren.amsterdam.nl in different tabs and clicking through them in parallel)
You still end up separating frontend and backend in full js codebases, but it's not as explicit and can lead to wacky/confusing/unpredictable behavior if you get it wrong. I've never found a perfect solution to the frontend/backend boundary but I've found a mix of declarative container type libraries (pydantic on backend, TypeBox on frontend) with some code generation is a good solution.
I work in a place where it's proper to wait for a month, get the openapi spec thrown over the fence from the backend team and generate my typescript RPC out of it. The upside is I don't get paged at 4 in the morning if the thing gets into a bad mood and starts doing increased 5xx at increased rate.
> Then somebody funds an RCE in server components.
I'd say they found it, but I love the conspiracy theory :D :D :D
Something happened to my brain lately and I started to make this kinds of typos in English, which I didn't before.
I'm 32, but I noticed I started making similar mistakes around 28 or so. Occasionally I write out words which are completely wrong, but sound similar.
It's as if one part of the brain is doing the thinking, and another one is "listening" to it and transcribing/typing it out, making mistakes.
For a little while I was a bit worried, but I then realized nothing else had changed, so I've just gotten used to it and like to jokingly say "I've become so fast at thinking that even I can't keep up!"
I suspect that as I got more vocabulary (and more languages) and started to actually speak the language more, I remember the "sound" of the word where I used to remember the spelling before. Like "it's" and "its" wasn't a problem before, but now I catch it somewhere in the text. At least I consistently write more than 50% of the articles nowdays. Languages are weird.
While I was writing the reply, I considered giving the absolutely exact same explanation, which I agree with, down to the example you gave.
Two examples in portuguese that always trip me up, and absolutely never used to before are (i) "voz" (voice) and "vós" (you); and (ii) "trás" (back) and "traz" (bring).
I also do a lot more code-switching.
Aside from the usual separation of tech stacks for different teams, the big thing for me is lack of any sort of type hinting or safety in templates at least in the big frameworks such as Django, Rails etc. I would much rather work with a separate build process that utilizes typescript than deal with the errors that come out of incorrectly reading formless data and making typos within templates.
Is that really such a big problem? These days you can type annotate what you pass to the rendering function for templates and then you know what type you have in the template. If you have a minimum of testing, heck even manual testing will do, I don't think too many mistakes make it to staging, let alone production. I would think it well worth to be able to opt out of the JS ecosystem.
Because JS is bad, and JS have a MASSIVE user base, so whatever they do is the web.
And because JS is on the frontend, solutions are front end, even the ones that eventually run on the (js) back-end.
Is like how people use a RDBMS but never do foreign keys, views, etc and re-invent all, poorly.
I had similar thoughts, but how does one use an RDBMS without making use of FKs? Do they put all in one huuuge table, that has all the columns and is super sparse? Or some other fever dream of bad design?
And is even worse, this is stuff that I have seen in ERPs (I integrate with several).
One of them, not even use "date"/"decimal" types and all is mostly strings, there is not views or anything else, and the tables AND fields are called "F0001..".
You can have a field with some value that just happens to match the id in a different table. That something could be a foreign key or just a number.
As long as you don't give a shit about data integrity, you don't need foreign keys.
In my experience it's boiled down to the type of data you're working with. Building nested, tree-like structures and then submitting that structure to the back-end as one request is more easily done via the front-end than a bunch of back-and-forth requests followed up by a "commit" request.
edit: I suppose this is different concern than a true SPA, but as another sibling comment points out, its just a matter of time before routing makes its way into the front-end as well.
For me, yes, it is. I make an app for myself, and I thought about making it a server-rendered app like you suggested. But it's just so much better in my opinion to do everything on the client side because it means that every interaction has zero latency, regardless of the quality of my internet (which is often bad).
I’d say that we are slaves to Conway’s Law.
Adding people to dev teams looks like an obvious way to scale productivity.
Then of course you need to organise them as the numbers grow and the frontend/backend split is the first, naive, place to start.
- Strict team separation (frontend versus backend)
- Moving all state-managament out of the backend and onto the frontend, in a supposedly easier to manage system
- Page refreshes are indeed jarring to users and more prone to leading to sudden context losses
- Desktop applications did not behave like web apps: they are "SPA"s in their own sense, without jarring refreshes or code that gets "yanked" out of execution. Since the OS has been increasingly abstracted under the browser, and the average computer user has moved more and more towards web apps[1], it stands to reason that the behavior of web apps should become more like that of desktop apps (i.e. "SPA"s)[2]
(Not saying I agree with these, merely pointing them out)
[1] These things are not entirely independent. It can be argued that the same powers that be (big corps) that pushed SPAs onto users are also pushing the "browser as OS" concept.
[2] I know you can get desktop-like behavior from non-SPAs, but it is definitely not as easy to do it or at least to _learn it_ now.
My actual opinion: I think it's a little bit of everything, with a big part of it coming from the fact that the web was the easiest way to build something that you could share with people effortlessly. Sharing desktop apps wasn't particularly easy (different targets, java was never truly run everywhere, etc.), but to share a webapp app you just put it online very quickly and have someone else point their browser to a URL -- often all they'll do is click a link! And in general it is definitely easier to build an SPA (from the frontender's perspective) than something else.
This creates a chain:
If I can create and share easily
-> I am motivated to do things easily
-> I learn the specific technology that is easiest
-> the market is flooded with people who know this technology better than everything else
-> the market must now hire from this pool to get the cheapest workers (or those who cost less to acquire due to quicker hiring processes)
-> new devs know that they need to learn this technology to get hired
-> the cycle continues
So, TL;DR: Much lower barrier to entry + quick feedback loops
P.S (and on topic): I am an extremely satisfied django developer, and very very very rarely touch frontend. Django is A-M-A-Z-I-N-G.
These days with 90% of SPAs being broken piles of browser standard breaking stuff, I find a page refresh or page load to be a soothing experience. They are like checkpoints in the process of using a website. Points to which I can go back using my browser's back button, and I can trust, that my browser keeps track of them.
In contrast, when I see an SPA, I need to worry about the whole site going to shit, because I blocked some third-party unwanted script, and then I need to fear not being able to go back properly, and having to re-do everything. Now that is a jarring experience.
I feel you. It's definitely a tradeoff. SPAs do tend to be buggier but I can't deny that, when done right, they also tend to be better.
Unfortunately, there's _more_ people, building _more_ stuff, so there's _more_ terrible stuff out there. The amount of new apps (and new developers, especially ones with quite limited skills) is immense compared to something like ten years ago. This means that there's just more room for things to be poorly-built.
Not being able to new tab to a new instance of the app is terrible. Even super complex SPAs like Facebook let me for the most part right click new tab to create a new instance while preserving the old one.
Google Maps. Gmail. OWA. There were suddenly pages that let you do things without a white flash between clicks.
It's ALL about the refreshes. Everything else came after.
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 !
Whenever I use Django, I enjoy it. Simple as.
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
both are so complex
Django is a modern web framework. It simply doesn't follow the hype around JS SPAs. However, if you really want to, you can of course still render static content + serve a JS framework like Vue to the client, and then have dynamic widgets rendered on the client side.
If you want to build an SPA anyway, then Django is not the right framework to start with though.
I use Django + DRF for SPA. SPA bundle is served from an nginx container, but I don't see any problem building it into the django image either.
What is the right framework for building SPAs?
Probably one, whose basic idea is to make an SPA. Django has all the tools for making a multi page website/application, which you are then not using. There is probably a framework that is based on the idea of making an SPA and that doesn't include the other stuff.
Have you tried Django with Inertia.js?
https://inertiajs.com/
Django + AlpineJS + HTMX is pretty nice.
That's just for the HTML content though. What if you want to add some non-trivial Javascript or generated CSS? Or maybe you want to integrate a frontend tool like Storybook[0] even if your HTML is rendered server-side? Maybe add some tests for your frontend code? There is much more between raw hand-rolled HTML/CSS/JS and a full-blown SPA.
At my day job we use Django with HTMX and Alpine, but we also generate the custom CSS from Pico[1] and use JinjaX[2] to define server-side components which we then render in Storybook. We use Vue as our bundler to compile the JS and CSS as well as to run Storybook. The project has to live in both the Python ecosystem and the Node.js ecosystem.
Even with just HTMX and Alpine you might want to compile a custom version of those with certain plugins, or you might want to load them as libraries in your own scripts.
[0] https://storybook.js.org/ [1] https://picocss.com/ [2] https://jinjax.scaletti.dev/
Especially with template partials now in the core of Django 6.
Yes the API process is very complex and then you have to have a team with proficiency in two parallel sets of web technologies -- python vs javascript. That said, the fact that you can go that route means that Django can be a good pick for early-stage projects where you don't need a frontend framework, because there's the optionality to add it later if your project really requires it.
I love Django. Thanks Django people, keep making great stuff.
What is the Java equivalent of 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.
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.
Isn't there Thymeleaf that alleviates that?
Forgive me, but thyme leaf is soft compared to ERB and jinja.
How about this? https://github.com/dropwizard/dropwizard
There used to be JHipster, not sure if still around
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
> Background Tasks.
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.
You will have to keep Celery for the foreseeable future. The current implementation is just a stub which provides a unified interface for some future backends.
Background tasks production backend is unfortunately the battery that is not included.
Meanwhile, Huey works just fine: https://huey.readthedocs.io/en/latest/django.html
I remember huey! Glad to see leifer is still maintaining it. I liked it way back when it first came out, was a breathe of fresh air compared to celery
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
[^1]: https://github.com/cookiecutter/cookiecutter-django
Django is awesome. I just prefer Rails because I prefer Ruby as a language. If you like Python then Django will get you very far.
Ruby is a far better language from a design standpoint and Rails is a better framework in both design and maturity. Sadly, Ruby is a domain-specific language for web backends these days. Most new startups pick Python and TS for their versatility.
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.
Glad to see someone on HN mentioning Strawberry! Hope you're enjoying it!
Django is awesome. Congrats team on the release!
Sad to see so little stuff related to async though :(
Thanks to Django. I got into the webdev world so easily.
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?
It didn't - https://www.djangoproject.com/download/#supported-versions
It's amazing, that django docs look and feel exactly the same the did in 0.9x. Damn kids with their JS bullshit have to change the whole site between v1 and v2 and then again when v3 happens. Links rot, API index is hidden and instead of text you get a dump of TS interfaces with zero comments.
/rant
Oh, looks more transparent.
Django needs a marketing push. I opened the website and immediately it smells like a 2011 web framework. Like CakePHP. Like Zend. Like Kohana.
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/
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.
Don't judge a web framework by it's website.
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.
Blog post yesterday: https://www.djangoproject.com/weblog/2025/dec/03/django-60-r... (https://news.ycombinator.com/item?id=46136516)
Show of hands for backend web services development -
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.?
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.
What should the options be? Were the ones I suggested coarse grained enough to capture everyone, or should I/we re-group or add more?
One proxy might be to look at the upvote counts for each of their respective latest release HN posts.
Eg, this post has ~50 (though only posted an hour ago)
Rails 8 had ~550
https://news.ycombinator.com/item?id=41766515
Rails might not get a lot of new articles about it, and the chatter might have died down, but I think a lot of people still use it.
It’s amazing how much rails devs feel the need to denigrate Django, feels like an inferiority complex.
I still have some very old Django projects that I'm maintaining for > 15 years. It's an absolute delight.
Yes. I'm still maintaining a Django site that I helped get live in 2007. I started learning Django in 2006.
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.
> I started using Django before the official 1.0 release
Indeed. I'm still using the 0.97beta. It's perfectly good for production use!
</obscure joke>
I've done several custom frameworks for solo projects in Java & Go, all based on server generated content, inspired by Seaside but more RESTy.
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.
Would love to see this.
Django just makes life 1000x easier. Can architect an app with data models, api, openapi, etc. within an hour.
In a company that uses a traditional web framework like Django to actually build the frontend and backend, not just as only for implementing the APIs, I would even consider doing parts of frontend work again, making everything responsive and so on. That's what I do for a not-yet-startup project.
As fully-featured as possible, because as much as I like building stuff, I don’t give a shit about coding stuff that has been figured out since the 90’s. Another question is whether semantics and operations get bloated or affect development speed in a framework but I don’t think it’s the case with the Django.
In what sense is Go not a traditional language for web services? They're almost the only thing it's good at, and it's been doing them for 13 years.
I agree that Go is a good choice for web services. I disagree that it's the only thing Go is good at. DevOps tooling and CLI tools immediately spring to mind.
Fair, CLI tools is why I said almost, but there's much more competition there. I wouldn't consider devops tools to be its own category though.
At work, it is mainly Kotlin and Go webservices with some Rust for very specific use cases
- Have written Rails and Django both
- Have written SPAs (React/Svelte)
- Have written Go based services
Each has their on pros and cons.
Perl, CGI.
Love it!
Which version of Perl are you using, and what type of service(s) are you maintaining?
Is this older software, or do you use it for new projects too?
Have you rolled any sort of framework yourself?
What are your thoughts on Raku?
I target 5.10.1 mostly. This is for a project I started in the late 90's. It uses CGI::Application, which is less a framework and more a method lookup table converter of queries (although I built a path info convertor on top of that). It's still maintained, although before Covid, it was my livelihood.
About a quarter of a million lines of code, excluding the libraries I pull in. I'm mostly self-taught, they wouldn't even let me get a minor in Comp Sci, since I didn't have the math background (Needed Calculus, I completeled Algebra 2 in hs). Boneheaded Uni.
Raku: Second-system effect poster boy. Sensationally dysfunctional community. I think Pugs is what was actually really incredible and Audrey is probably one of the most intelligent people in... the World? Up for contention, but top 10.
Fable (just for the fun of it) and the new one dot net one file web services that resemble flask