Sorry, sometimes I make jokes.
User facing Django apps from SaaS’s to educational portals to CMS’s need to allow users to make and see changes without affecting the full request/response cycle, and frankly, this often grossly simplifies the application too (imagine having to code every possible template state individually).
That’s left for you.
This is a trick question because there isn’t a “best” answer across Django sites.
Years ago Rails shipped with Prototype.js and so that’s what Rails uses ended up using. It was considered a mighty shame that Django didn’t ship with such support built in since AJAX was all the rage.
It is a little when you think that even Django’s configurable components have defaults or community conventions (templates and backing databases come to mind). However we draw the line at the HTTP request, which means we have to figure this one out ourselves.
Your first consideration should be what are you trying to accomplish. Do you need to add some minor interactivity (modals, dropdowns, etc) or the equivalent of a single page application?
Next, how extensive throughout the app and the code are these changes? That is, is it cheaper to repeat code or repeat patterns?
It’s better to be conservative here rather than pick something that seems full feature for the app you want to build in two years. Personally I think Elm[x] is a cool choice but the buy-in in non-trivial. React is a perfectly fine and justifiable choice but setting up a complicated immutable data store with Redux is often overkill. Overkill is expensive.
If you don’t have an API you’ll either be working with in-page JSON or data from your templates. This is a constraint you need to pay attention to, especially if you want to build any kind of client interaction consuming and sending data to the server. Some frameworks make working with data from the DOM easier than others.
Our own go-to workhorse for a while now has been Vue.js; it plays nice with jQuery, it brings to bear the design patterns required by larger client side application and it can still scale down to individual features.
But I’m still not going to tell you that it’s the one you should choose.
Learn from more articles like this how to make the most out of your existing Django site.