We are using Django "Legacy" Apps.I am puzzled by the "new" Single Page Applications (SPAs). They require extensive routing, authentication, and GraphQL integration, all of which are already handled by Django's ORM and views.Additionally, Django efficiently manages forms. The primary advantage I see in SPAs is enhanced reactivity, which certainly improves user experience. However, HTMX seems sufficient in this aspect.What would be your sales pitch to someone like me?

Twice as much code for the same functionality. They are better if you have a heavily interactive frontend. But th majority of apps don't need that. Github uses a traditional server side renderrd app, if I am not mistaken, and no on has complained about that.

Github is moving to an SPA with init-time SSR.

Broadly, if you're happy with Django and haven't felt the need to transition to SPA, power to you. This is the case in some industries. It's generally not the case in b2c, though, and if you haven't felt the pain yet then you likely aren't in touch enough with your customers (or you haven't connected the dots).

I don't need to sell you on the concept though I will address your comment in depth.

In general, React (especially with typescript) provides a far better developer experience than Django+Templates. The latter is extremely brittle, difficult to test, difficult to refactor, difficult to organize. The former is robust, typed, testable, easily refactored. It's simply quicker to work with React. And this has quadratic effects on how quickly work gets done: The whole stack is easier to work with, which has gains on every level such as learning pace, testing, including third party libraries, deploying, finding and fixing bugs, ...

The advantages of an SPA are an extension of this. You get to move more logic in this frontend layer. Routing at the frontend layer is mainly a performance thing: You don't get to re-download and re-render your entire page when going from, say, viewing "Produc 1" to viewing "Product 2". The whole structure is the same but the content changes = you should only get to update the content, right? If you handle routing at the frontend level, this is something you can achieve.

But routing in frontend also enables some new things you just cannot easily do without it. For example now it's trendy to have apps that open content (such as a post) which opens in a preview window/drawer (saving your current state), but if you reload the page or share the url, it loads in its own individual view. Why is it trending now? Because SPAs have enabled that behaviour.

GraphQL integration is definitely not something that is required, and in fact in ~30 client projects of this type, I've only ever done it twice, for two people it was actually relevant for.

But: You generally want an API anyway. Writing your frontend<>backend communication as an API means you can offer it to your customers as well. It's a good pattern to follow, IMO. And if you're going to have that API, then separating the frontend into an SPA is much easier, because you can use that API to drive all the communication. This makes you a user of it (dogfooding).

As for forms -- Almost all form validation should happen both in the frontend AND in the backend, this is a textbook case of something which should be (mostly) duplicated. The backend MUST validate the input at some layer, lest you end up with security issues. But the frontend SHOULD also validate it, because it's a terrible experience to fill in 15 fields, submit, then see a "please correct the errors below" message with 3 of your fields red, your chosen password gone, the captcha to re-do, and that's if you ever manage to get good errors out of the backend because sometimes it just says "This value is invalid" and you have to manually figure out what's happening there (which for normal people means you'll sometimes hear "your X form didn't work" with zero additional feedback).

I’d also add that if you use Typescript with an OpenAPI client generator (https://github.com/ferdikoomen/openapi-typescript-codegen) it can immensely alleviate some of the biggest pain points of seperate backend and front-end. It always used to be a major pain in the ass with the amount of overhead an API change would incur - updating documentation, postman, constant communication between backend and front-end devs, etc. Now I just npm run generate, I see new API changes in my Git client and Typescript errors for code that needs updating.

Also, using a library like Tanstack Query or Rdtk Query can almost completely eliminate manual state management, and kinda makes the whole development experience feel almost like SSR.

> constant communication between backend and front-end devs

Curious, are you doing anything in your code-generation workflow to solve this specific pain point?

I should have been more specific, the codegen alleviates a large portion of back and forth that would have otherwise been spent asking the backend devs things like “why isn’t this working”, or “what has changed”. There is still a lot of communication involved, but it relates more to the business objectives and less annoying fiddly things. For my current project the backend devs are using a cumbersome enterprise stack - the one saving grace for me being that they have swagger (OpenAPI) docs. As a front-end dev the codegen really helps to shield me from a lot of implementation specific backend stuff, as if the interface changes I am going to be informed about it from the Typescript compiler. Also one really great feature is that specific values for validation, such a min/max character length are also exposed and generated with the codegen so that is also another bunch of variables that I can worry less about when I implement clientside validation.

I’d really recommend taking a look at the tool I linked. I see a bunch of end-to-end Typesafety tools mentioned like GraphQL, Protocol Buffers, etc, but they seem overly prescriptive to me, and most of the time you are gonna be working some basic REST service and an OpenApi/Swagger doc is the best you are going to get from the backend devs.

Mobile

I've gone the opposite way. Started converting views to rest framework viewsets and building React components on the front end. It just created more problems. Now the React stuff is considered legacy and we're using HTMX and the bare minimum of vanilla JS when necessary.

REST Framework is frankly... flawed. Full of good ideas, but in practice, it leads to development hell unless you're very rigorous with it.

FastAPI is the gold standard, which in the Django works means Django-Ninja.

If you've been building individual React components and integrating them without going the SPA route, then while there are some upsides to that, you are doing a lot of the effort but not getting most of the benefits.

If you don't need an SPA, then you don't need an SPA. Nobody should be getting this development pattern shoved down their throats. But from what you describe, it sounds to me like you went with a bad approach altogether, so no kidding it created more problems.

(Not to make it sound like a "no true scotsman" with the whole "bad approach" thing, but this is why it's important to get people who really know their shit in driving refactors like these, and can make a strong plan ahead of time, detailing what value is brought at each and every step)

The lesson learnt is that React is an "all or nothing" type thing. You'll notice "SPA" isn't mentioned at all on the React website, but there's lots of mentions of building components. There are lots of comments around places like HN of people learning the same lesson as me. We never scoped replacing our entire UI with React and entire backend with JSON API because it seemed like there was a smooth upgrade path, but there isn't really.

As for people who know their shit, how do you think said people learnt their shit? Everyone can do what they already know. The interesting stuff is on the frontier of your knowledge. You learn by pushing that boundary and, when you fail, thinking about why it failed.

React isn’t all or nothing… you can upgrade bit by bit, extremely incrementally. But if you’re mix and matching frameworks and paradigms together then yes expect to not get the full value.

It’s like judging Django when only using it for its utils package and saying it’s “all or nothing”. Django isn’t really all or nothing either but you won’t get its full value if you just use it to supplement Wordpress for a single endpoint or something.

> because it seemed like there was a smooth upgrade path, but there isn't really

You can put a React component into a non-React web page and give it data to render from however you like. Isn't that the intended path?

Yes, and that is indeed what we did. But what happens is you end up with a backend awkwardly fragmented into restframework viewsets and normal Django views. Often you end up having to maintain both. And then your frontend is in two distinct "worlds" which are developed in completely different ways. Unless you finally get to having an SPA and only JSON on the server side you'll feel forever in limbo. HTMX just makes so much more sense for an existing Django project unless you can afford to stop development and go all in on React, and even then only if it's really necessary to have an SPA.

Yeah - agree that the Django path to add REST endpoints alongside HTML ones is not the best. I like Flask for this reason: it walks the line between HTML rendering and JSON responses really well, IMO.

> Now the React stuff is considered legacy

There's no point announcing things are now "legacy". Legacy is what Microsoft invented to call products they just made a competitor for, and the psychology seems the same. If it doesn't fit your needs, great. But React is useful for lots of needs.

I didn't mean React is legacy. You can't replace a React app with HTMX in general. I just meant within my project. Those parts are now unmaintained and will be replaced when they break or if we need to change them.

Oh! Sorry - hope you enjoyed my overboard response :)

What do people like torturing themselves by duplicating code. Wouldn't it be easier to just use node all the way.

Writing hundreds of lines of JS to display a Table list, instead of HTML sprinkled with some JS

A whole stack rewrite is not always (in fact very rarely) a good idea. The backend often drives a lot of logic; in a big rewrite, the less you rewrite the more likely you are to be successful.

Too many big refactors fail because they aren’t done in value-adding steps.

Also your second paragraph isn’t in line with your first … in react you don’t write “hundreds of lines of js” for a table. You write the html as js (jsx), and sprinkle the dynamic parts on top. It’s equivalent…

I've seen, routing boilerplate, js to make the api requests, js to modify state(redux), unit tests, interfaces, until you get to the actual table.

No thanks, I prefer to drop React and use django + htmx for ajax.

Hey, if you're happy writing html using not-quite-jinja templates that are completely impossible to test, auto-format, or even sometimes syntax highlight...

what can I say, power to you. You go, buddy.

You can integration test, you can use the debug plugin for htmx, you can format them with vs code extensions, and there is a highlighter available, though it’s not that important seeing as how each attribute is pretty simple.