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.)
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.
Edit: Background tasks for light work are also included in this release.
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.
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!!
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.
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.
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
If you want to build an SPA anyway, then Django is not the right framework to start with though.
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/
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.
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.
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.
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
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 funds an RCE in server components.
You are here.
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...
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.
It's ALL about the refreshes. Everything else came after.
- 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.
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.
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?
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.?
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.
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.
Eg, this post has ~50 (though only posted an hour ago)
Rails 8 had ~550
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#).
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.
Indeed. I'm still using the 0.97beta. It's perfectly good for production use!
</obscure joke>
Django just makes life 1000x easier. Can architect an app with data models, api, openapi, etc. within an hour.
- Have written SPAs (React/Svelte)
- Have written Go based services
Each has their on pros and cons.
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?
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.