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.
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).
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.
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.
And because Django is so popular in open source projects and it has been around for such a long time, there's tons of code out there for AI to train on.
Claude is insanely good with Django and React. I think the best thing that happened to Python was type hints because it lets LLMs reason Python code easier.
why would you need batteries included? the ai can code most integrations (from scratch, if you want, so if you need something slightly off the beaten path it's easy
I 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!
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 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.
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).
Django was my first big freelance project, and still feels tremendously cozy to use. I've done some goofy things with it and it's always served me really well. Thank you Django
Using Django for almost 15 years, almost exclusively, for both business and personal projects. Have tried a lot of other frameworks, nothing clicks so good with me.
My only (small) complain with this release would be that they included the task framework but didn't include a task backend and worker. I'd prefer to wait a bit and include everything in the next version.
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.
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.
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 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?
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.
- 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.
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 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.
Readit News
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.
Nick, thank you for sharing so much in the open.
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.
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.
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.)
It is rather sad for humanity that good ideas through-out time have been lost thanks to neurodiversity / social-acceptability constraints.
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.
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.
Dead Comment
Edit: Background tasks for light work are also included in this release.
Dead Comment
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!!
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
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.
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 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.
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.
Frontend wise, Django is in the Stone Age.
Look at Laravel or rails if you want a really complete full stack solution.
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.
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/.
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.
PWAs/Webviews/etc are not really practical options.
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.
Everything since then was an attempt to leverage JS to turn documents into applications. Why? Ask any user.
Smartphones on the other hand...
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)
I'd say they found it, but I love the conspiracy theory :D :D :D
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.
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.
- 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.
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.
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.
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.
It's ALL about the refreshes. Everything else came after.