I.e. looking for solutions that "render HTML in Django, and use Javascript to enhance the server-rendred [sic] HTML."
HTMX is the most popular solution.
which i think is, for the most part an exaggeration.
if someone feels that learning a new framework is heavy and has a steep learning curve, then either they are juniors that need more practice and experience, or they have never tried learning a second framework, or they have become lazy. (but here i'd also like to blame employers that don't give their developers time to learn new stuff)
If an application has lots of client-side state (and the framework to support that), for example, that means you have a whole additional lifecycle of your code to reason about. Whereas if it at most sets a disabled attribute on a button, that's conceptually a whole lot lighter.
not really, because you no longer need to track that state in the backend. the backend can be reduced to data storage and business logic calculations. the cases where you need track some state in both frontend and backend should be rare. from my experience all the UI code is moved from the backend to the frontend. it's not being duplicated.
duplication of code can happen during a transition, but it should be temporary
and if i specialize, i'd do it with one frontend framework and one backend framework. ok, so that's two instead of one. anyone beyond a junior developer should have no problem with this.
what's more, this simplifies the backend so much that in most cases it is reduced to CRUD in such a way that i can reuse it more easily. since using frontend frameworks i haven't in face needed to do any backend coding anymore because i could just reuse the backend i already had unchanged. so in my case, i only ever had to deal with one project, except for the first time where i wrote the REST API into the backend. every other website after that was a frontend project only.
for dozens of projects i can now maintain a single backend implementation (with multiple instances as needed, that all share 100% of the code). that alone makes using a frontend framework worth it even just for a few simple client-side effects.
If you are, then sure, those frameworks are conceptually lighter.
being comfortable in Django and wanting to keep that
is a bad idea. because whoever is doing that is missing out on a lot of potential.
sure, there are many cases where sticking with django for everything is the right choice, but that's not always true, and i am trying to argue that there is a benefit to exploring the alternative.
i was a backend developer too, django, laravel, others,, and i shunned javascript as much as i could, but when i discovered angularjs (the first version, before it was popular) it just won me over as the better way to build frontends.
in particular, not having to track state in the server, i feel, makes the whole development process so much easier.
i could summarize it thusly: i would use a lightweight option only if the site is mostly stateless (which many content sites tend to be) but as soon as it is necessary to track state, i find a frontend framework talking to an API is the better choice, because tracking state in the browser is so much easier.
And most importantly, the amount of fragile ad-hoc, potentially abandonned "concepts". I have a very different feeling when I grind hard to learn about physics or maths compared to IT solutions. The latter almost always feel empty and very temporary, which causes fatigue to rise way faster.
btw, i use frontend frameworks without bundlers/build steps, but load then statically straight into the browser. that may seem a bit wasteful, but it dramatically simplifies the maintenance needs for a site, guaranteeing that the site will keep running and be maintainable for the forseeable future.