I don't think anyone's complaint about server side rendering has ever been that it was too complex.
Then you get into things like how no server side rendering strategy has the equivalent to React “just write an inline helper function for this page”, so you need to create partials in files all over. And what if you’d like to statically verify that your templates have all the content in place? Proper typing? Who hasn’t had a page fall over because there was some missing context variable 3 layers deep.
The thing with the API based flow and client side rendering (with React at least) when you have it set up nicely is “add a list view with pagination and search with a modal to create a resource if needed, and some inline editing” can be done by opening a single file and getting there with 2 dozen lines. Server side rendering strategies in practice tend to buckle a bit if you try to be modular enough, and in many cases you need to open one file per checklist on your project. Code locality issues are real IMO
Disclaimer: I’ve done both, messing around with HTMX on a project and think it’s pretty cool. But it’s mainly because I don’t have all of the nice patterns from work projects that I’m tying this. If startup costs weren’t a thing I’d go with a client side system most days of the week.
But so far we’ve landed on using the django-components library [1] to build something akin to Vue’s single file components. HTML, CSS, JavaScript, and Python “business logic”, all in one file.
That component is then used in the Django templates, or in other component’s HTML, and it all seems to work very React-like in terms of an organized structure of composable components. Combined with HTMX the traditional SSR challenges you mention seem fairly straightforward to handle.
> what if you’d like to statically verify that your templates have all the content in place? Proper typing?
Can you say more about this? Would this be using TypeScript in React to verify types, or something more involved? I’m trying to understand this and what the equivalent might be in this “dynamic SSR” scenario.
I think django-components only has part of the story there, because even if that helps writing out your page, you're still looking at going to the other side of the frontend/backend wall to add, at the very least, an endpoint using that template. And if you're following this whole "hypertext API and data API as separate things", you'll need to also code handling of submitting any data, and routing involved.
I'm not against this stuff entirely, because I think there's a bit of a Go-like niceness to how it's "at worst" boilerplate (that you can abstract over on a per-project basis). But if you have a comfortable, well designed API all that work spread over you templates and controllers might actually all just be in one place.
They added real-time search results to our Django SSR site in 2 lines of HTMX.
It’s the opposite of added complexity.
IMO, it's a great option for rapid prototyping and for projects that can be done with whatever backend stack you already have.
Lots of use cases could benefit from a hypermedia flow.