Modern JavaScript for Django Developers
48 comments
·January 15, 2025singhrac
I've tried several boilerplates like SaaSPegasus and one thing I can't really get around is that I feel like the experience of developing in a docker-compose with two build-and-serve containers (e.g. one with gunicorn auto-reload and the other running something like esbuild for the frontend) is very clunky in VSCode?
I feel like I'm doing something crazy, this must be a problem many other people have, but things like language server integration on the JS and Python side separately do not mesh well.
If anyone sees this and has a minimal open source boilerplate to recommend I'd love to try it.
tubs
Why do you need docker to run esbuild? It’s a static binary.
ggregoire
I've seen some companies using React with Django REST Framework [1], to keep the benefits of Django while having a strong separation between front and back (separate projects, teams, deploys, etc).
holler
DRF has been around a long time at this point, and that's been a common stack (albeit with other frontend frameworks 10 years ago).
In recent times I'm a fan of Starlette, which is what the popular FastAPI lib is built on top of, and created by same author as DRF.
ryannevius
We use Django and django-ninja [1] and like it MUCH better than DRF.
bkovacev
Care to elaborate further? I keep reading on this, but no one actually mentions anything specific that ninja does better than DRF.
nilsbunger
This is an excellent article, and SaaS Pegasus is a great solution for people starting a project.
But some of the advice here is dated. The architectural patterns are still valid, but the specifics have changed:
* Vite instead of create-react-app (which is unmaintained now) / webpack / babel / Parcel / etc.
* Django-ninja as a lightweight API service.
I think these are important to call out because they really simplify the frontend compared to the previous options.
bkovacev
What seems to differentiate django-ninja over Flask or FastAPI or any Starlette derivative? You mention lightweight as well, can you expand further?
jilles
I don't think Alpine.js and HTMX qualify as "Modern JavaScript". There is an approach that is rarely talked about: render templates in Django and hydrate using your favorite JavaScript framework.
For example the Django template renders a <template id="abc"><button disabled>open modal!</button></template>. Then your JavaScript bundle can "hydrate". For example ReactDOM.render(<OpenModalButton />, '#abc'').
You just have to be diligent to make sure that the template and your front-end have somewhat similar markup to not have layout shift. It's really not that hard and works for a lot of use-cases.
Not saying this is a golden bullet, but you should be able to figure out which parts are static and just render them using Django templates. The dynamic parts you can render/hydrate using whatever front-end framework.
I built a Django app with very little JavaScript and only using HTMX and it was... alright. It works. I can say "no fancy build step!" but I totally miss the testability of modern frontend. Creating an image upload component was a pain. I don't think I would use HTMX again and instead go for the hybrid approach I described earlier.
azemetre
Why wouldn't Alpine.js and HTMX be modern javascript? They're both written with modern javascript.
React was created in 2013, Alpine in 2020, HTMX 2020. React is the elder of the bunch. React is the bloated tool nowadays.
drdaeman
Personally, I don't think the term "modern JavaScript" makes much sense - it's just a nice-sounding but mostly meaningless buzzword, but I can guess the reason about the disagreement.
Alpine and HTMX are entirely different architectural approach to script webpages, as compared to React/Vue/Svelte/Elm/... approach to build SPA webapps. And the latter approach was very frequently called "modern JavaScript" (and that's why I think it's more of a buzzword now, and less of an actually meaningful term).
evantbyrne
I can't speak for HTMX specifically, but going to progressively enhanced server-rendered HTML from React requires a certain amount of mental deprogramming. I've been using Turbo lately for side projects (e.g., Pocket SQL) and found it involves working much more closely with browser APIs, but also writing way less UI code. Pocket SQL required writing about 50 lines of JS and people probably wouldn't notice that it's not a SPA unless they looked under the hood.
rob
That's "Part 4" I believe:
https://www.saaspegasus.com/guides/modern-javascript-for-dja...
dimgl
I was doing with this Knockout back when I was using ASP.NET MVC! I'm surprised it's not a more common pattern.
fmnxl
Having used HTMX and Unpoly with Django, for over 2 years now, I prefer using Unpoly more these days.
Unpoly feels just like Django, it is a more of a framework than a thin layer, but that means it comes with a lot of productive features built-in, albeit opinionated.
It covers 95% of the use-cases of a typical web app, with its layers and forms concepts. E.g. I love creating "subinteractions" with unpoly, where a complex process can be divided into smaller modal forms for creating the "related" objects of a model, which then updates the main form of the model itself. Unpoly makes these simple, and its documentation caters for exactly these scenarios.
giancarlostoro
Having done Blazor with C#. I just want Django to have its own version of Blazor. You never have to touch JavaScript, and / or if you do, its very sparingly. Your front-end either runs AJAX style, or fully in WASM depending on your needs.
I have built some wonderful UIs with Blazor in drastically less time than I would have spent building a JavaScript UI.
HTMX and might be the closest thing to what I'm describing that is actually available for Django today, though minus the WASM capabilities.
leetharris
Laravel has something like this called Livewire. It's excellent.
Laravel is so much better than Django, but I just can't go back to PHP at this point.
nop_slide
I thought the same. I evaluated the "big 3" (Laravel, Django, Rails) last year and decided to go all in on Rails for solo side web projects.
Was really wanting to like Django since I'm a python dev for my day job, but it didn't have nearly the amount of DX and tools baked in as Laravel/Rails.
Rails has been super fun, I hadn't touched it in 10 years and the additions that versions 7/8 have brought are awesome.
adamrt
I've heard people complain about Django many time on HN. I started using it back in the 0.96 version, so maybe its just a familiarity thing.
But I built 3 large successful applications in it in that time. I loved it. I don't use it regularly anymore since I mostly moved away from webdev, but I recently came back into contact with my largest project I build in 2018/2019 and its been running perfect this whole time and was a pleasure to dive back into.
Django just felt logically organized, documentation was on point, core was very readable (at least then).
I always just felt so productive in it. I know everyone has different opinions, experiences and products they are building, but I'm always surprised with the negative comments. I definitely prefer SSR with its reasonable though, so maybe thats part of it.
oooyay
Most of the complaints I've read about Django on HN have to do with ASGI support - which Django added. They're valid but outdated complaints.
pier25
> I just can't go back to PHP at this point
Same.
During 2024 I evaluated multiple backend platforms/frameworks to get away from Node. Laravel is great and modern PHP (the language) is also surprisingly good but betting on PHP feels like betting on coal and the steam engine. The runtime and execution model are extremely outdated and resource hungry.
There are some efforts like FrankenPHP and Swole that package a PHP app to have a persistent execution model. But IMO unless PHP officially adopts this model this will always feel like a hack to me.
morbicer
The job market for php devs is also weird. Very few talented people. Because php jobs on average pay the worst, people who are motivated and smart often learn another language and abandon php. There are some very practical oriented and clever people willing to do php but you have to look very hard.
rob
What did you end up going with if not PHP/Laravel?
cjohnson318
I'm not sure why this has been downvoted so much, this guy states something that might upset some people, but then goes on to provide a pretty sober list pros and cons. This is the kind of content that we want to encourage on HN.
lawn
And Phoenix/Elixir has LiveView, also excellent.
lowercased
Is unicorn close?
https://www.django-unicorn.com/
Wouldn't be WASM based either, but most of these types of tech aren't (yet?). I'm in the livewire camp with Laravel. I found a bit discussion of a webassembly version of livewire, but I don't think it's on the cards any time soon.
selecsosi
Typed view model bindings to templates was always amazing and 100000x more ergonomic than WPF (in my experience). That being said with so many things going to client apps, I'm less inclined to go w/ server side rendering and treat my backend as a data API so I'm not stuck building that twice.
neonsunset
If you liked Blazor (and it's interesting to hear perspective of someone "outside" the .NET bubble), is there a reason to prefer Python and Django?
null
yoyohello13
BTW, this guy's Django templates are really good.
chis
I wish there was some way to just get react-style data bindings, html generation from JS, and code organization, while still hosting from purely a flask/django backend. The traditional split of a flask API and a react frontend consuming it, just feels like overkill.
Plus native JavaScript+html is just so close to a complete solution these days. I don’t miss components at all. I just want better code organization.
joshlemer
I have found that inertia.js is a great solution, it basically allows you to program in your traditional back end multi-page application, MVC kind of style, but with all the benefits of an SPA. So, you get to skip writing an API and just pass data into a view like in the old days, but the view is a React component (or Vue or Svelte)
morbicer
I don't understand the second sentence. As someone developing web apps for over 20 years, components ARE the better code organization.
fmnxl
Well there's a cost to that abstraction, e.g. you'd have to pass the context into the component, so every time you need to modify the component's schema/props you'd need to change it twice, both in the parent and the component.
You must have seen some huge React components with 20 different props or even more, and you'd need to think about memoizing those props to prevent a re-render, etc etc.
I've also been a web dev for over 20 years, and 10 years with React. I'd say that going back to native HTML APIs for handling stateful things like forms and form validation is a breeze, rather than writing components and endless abstractions. It's enough for the vast majority of the time.
morbicer
Those are just shitty codebases. I maintain a React app that's over 10 years old, almost milion lines of code and we have zero components with 20 props, no issues with performance or whatnot.
I am an oponent of over-abstraction but components are very light abstraction and provide just sensible encapsulation and reusability.
0xblinq
Check out https://inertiajs.com/.
I've never used it with Django (there's an adapter here https://github.com/inertiajs/inertia-django) but I did use it a lot with AdonisJS and Rails.
It's wonderful. The best of both worlds. TL;DR you can use React/Vue as your "template" layer and keep everything in your batteries included backend framework of choice, avoiding all the bull**t and madness going on with Next, Remix, React Router, etc, etc...
cdfuller
This guide is a bit over two years old. Can someone comment on whether it still holds up and the tools recommended are still being recommended today?
czue
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.
I think this is a great resource but wish it had not chosen a hybrid architecture. All the guides on decoupled Django seem to choose hybrid. It makes sense because you get the CSRF / XSS safety benefits but I'd love to see how others tackle a fully decoupled Django stack e.g. oAuth, JWTs and how they do their CSRF / XSS security. It's an area I need to learn more about.