As someone who has been writing code for 30 years and has been developing "web apps" since the late 90s, it's really funny to me how things come full circle.
You just described the entire point of client-side rendering as it was originally pitched. Computation on the server is expensive and mobile networks were slow and limited in terms of bandwidth (with oppressive overage charges) just a few years ago. Client-side rendering was a way to offload the rendering work to the users rather than doing it upfront for all users. It means slower render times for the user, in terms of browser performance, but fewer network calls and less work to do server-side.
In other words, we used to call them "Single Page Web Applications" because avoiding page refreshes was the point. Avoid network calls so as to not consume bandwidth and not make unnecessary demands of the server's limited computational resources.
Now things might be changing again. Mobile networks are fast and reliable. Most people I know have unlimited data now. And while computation is still one of the more expensive resources, it's come down in the sense that we can now pay for what we actually use. Before we were stuck on expensive bare metal servers and we could scale by adding a new one but we were likely overpaying because one wasn't enough and two was way overkill except for peak traffic bursts. So we really scrambled to do as much as we could with what we had. Today it might be starting to make sense to make more trips back to the server depending on your use case.
To address your concern about latency or outages, every application needs to be built according to its own requirements. When you say "there's not a perfect solution to this", I would say "there is no one size fits all solution." We are talking about a client / server model. If either the server or client fails then you have failed functionality. Even if you can get yourself out of doing a fetch, you're still not persisting anything during an outage. The measures that you take to try and mitigate that failure depend entirely on the application requirements. Some applications strive to work entirely offline as a core feature and they design themselves accordingly. Others can accept that if the user does not have access to the server then the application just can't work. Most fall somewhere in between, where you have limited functionality during a connection interruption.
There's nothing wrong with loading a page and then everything on that page loads data from the server and renders it.
Where the issues come in is that modern SPA claims loading a new page is unacceptable and that somehow doing so means you can't fetch data and render anymore.
> we used to call them "Single Page Web Applications" because avoiding page refreshes was the point
I wonder if the problem was really that the whole page was reloaded into the browser which caused a big "flash" because all of the page was-re-rendered. The problem maybe was not reloading the page from the server but re-rendering all of it. Whereas if you can load just parts of the page from the server the situation changes. It's ok if it takes some time for parts of the page to change because nothing gets "broken" while they are refreshing. Whereas if you reload the whole page everything is broken until all of it has been updated.
The problem was there was no concept of reusable components. IMO htmx is not the headline here but django-components (https://pypi.org/project/django-components/) is. Managing html, css and JS in component-reusable chunks on the server used to be extremely awkward, especially when you begin to need lifecycle events (HTML appeared on the page, lets attach all the necessary event listeners, but only to the right element - even in a list of 5 elements; internal HTML changed, lets see which things need more events etc).
I would try this approach out in a typechecked language, if I'm certain a native mobile app isn't going to be needed.
The difficulty with web-development is there are 3 different languages (HTML, CSS, JS) which all need to make some assumptions about what is coded in the other languages. The JavaScript refers to a DOM-element by id, it assumes some CSS which the JS can manipulate in a specific way.
The ideal goal much of the time has been: "Keep content separate from presentation, keep behavior separate from the content etc.". While this has been achieved in a superficial level by keeping CSS in a .css -file, content in a .html-file and behaviors in a .js -file, they are not really independent of each other at all. And how they depend on each other is not declared anywhere.
That means that to understand how a web-page works you must find, open and read 3 files.
Therefore rather than having 3 different types of files a better solution might be to have 3 files all of which contain HTML, CSS, and JS. In other words 3 smaller .htm files, each embedding also the CSS and JS needed.
You just described the entire point of client-side rendering as it was originally pitched. Computation on the server is expensive and mobile networks were slow and limited in terms of bandwidth (with oppressive overage charges) just a few years ago. Client-side rendering was a way to offload the rendering work to the users rather than doing it upfront for all users. It means slower render times for the user, in terms of browser performance, but fewer network calls and less work to do server-side.
In other words, we used to call them "Single Page Web Applications" because avoiding page refreshes was the point. Avoid network calls so as to not consume bandwidth and not make unnecessary demands of the server's limited computational resources.
Now things might be changing again. Mobile networks are fast and reliable. Most people I know have unlimited data now. And while computation is still one of the more expensive resources, it's come down in the sense that we can now pay for what we actually use. Before we were stuck on expensive bare metal servers and we could scale by adding a new one but we were likely overpaying because one wasn't enough and two was way overkill except for peak traffic bursts. So we really scrambled to do as much as we could with what we had. Today it might be starting to make sense to make more trips back to the server depending on your use case.
To address your concern about latency or outages, every application needs to be built according to its own requirements. When you say "there's not a perfect solution to this", I would say "there is no one size fits all solution." We are talking about a client / server model. If either the server or client fails then you have failed functionality. Even if you can get yourself out of doing a fetch, you're still not persisting anything during an outage. The measures that you take to try and mitigate that failure depend entirely on the application requirements. Some applications strive to work entirely offline as a core feature and they design themselves accordingly. Others can accept that if the user does not have access to the server then the application just can't work. Most fall somewhere in between, where you have limited functionality during a connection interruption.