Author here. I would say the core principles still hold up well, though the tooling and libraries are constantly evolving.
An incomplete list of things I'd add / change today (and are on my roadmap to cover in more detail):
I would probably recommend Vite over Webpack as the main bundler/builder, as it's faster and rapidly taking over as the default tool to solve the same use cases.
The other gap that is missing is a treatment of the "nobuild" options that exist today. Essentially things like ES modules and import maps and other stuff that lets you (if you want) run a lot of modern JavaScript libraries with zero toolchain directly in the browser.
I'd also want to revisit the fully decoupled approach a bit more. With the advent of LLM-based tools that can generate complete front ends for you, as well as libraries like shadcn, there is a larger upside to adopting the complexity of the decoupled API set up, even if it definitely still is slower and more painful for anything that touches the backend.
Django ninja has been gaining traction against DRF as an API library and the developer experience and performance are definitely better, though DRF still has way more batteries in terms of 3rd party library support for various use case.
The Django + HTMX + Alpine stack has only gotten more widely adopted since I published Part 5, and I'd say that part has held up quite well in the "low to no JavaScript" ecosystem for Django, and is the default choice for many Django devs now.
The low javascript django approach definitely appeals when starting a project, but I'm trying it and feel like I hit an awkward patch very quickly: submitting nested forms.
For example, an Allergy can have many Reactions, a Reaction can have many Manifestations. The form layout looks like it should capture which Reaction a Manifestation has a foreign key on:
Allergy
-Reaction 1
--Manifestation 1
--Manifestation 2
-Reaction 2
--Manifestation 3
But when you actually click submit, it's not easy to figure out which Reaction a Manifestation is on. Asking other places it seems like there isn't great html support for nested forms. So any solution is either going to serialize the form on the client side to a json before sending, or some inline formset factory solution. I feel like submitting nested forms must be a common case, but none of these have the simplicity I hoped for of django taking the request.POST and giving me the allergy, its reactions, and for each reaction their manifestations.
Do any of the solutions in your guide fit particularly well? Would your client send it as a json? Feel like you must have come across this and curious what your choice would be. In any case thanks for the article.
An incomplete list of things I'd add / change today (and are on my roadmap to cover in more detail):
I would probably recommend Vite over Webpack as the main bundler/builder, as it's faster and rapidly taking over as the default tool to solve the same use cases.
The other gap that is missing is a treatment of the "nobuild" options that exist today. Essentially things like ES modules and import maps and other stuff that lets you (if you want) run a lot of modern JavaScript libraries with zero toolchain directly in the browser.
I'd also want to revisit the fully decoupled approach a bit more. With the advent of LLM-based tools that can generate complete front ends for you, as well as libraries like shadcn, there is a larger upside to adopting the complexity of the decoupled API set up, even if it definitely still is slower and more painful for anything that touches the backend.
Django ninja has been gaining traction against DRF as an API library and the developer experience and performance are definitely better, though DRF still has way more batteries in terms of 3rd party library support for various use case.
The Django + HTMX + Alpine stack has only gotten more widely adopted since I published Part 5, and I'd say that part has held up quite well in the "low to no JavaScript" ecosystem for Django, and is the default choice for many Django devs now.