Yeah exactly! Figure out where your application can't afford reloads and build for that when appropriate.
The whole attitude about page reloads "feel like dial up in the 90s" is a little over the edge: when I navigate between pages in Slimvoice there isn't even a white flash. If your server is efficient and you don't try to load insane gobs of data, it's not as big a deal as the SPA zealots make it out to be.
Pick the right tool for the job, not reaching for what everyone else is smoking today.
You're right, the pages changes in Slimvoice are barely noticeable, the UI feels slick and responsive, everything looks and feels lightweight.
If you need to scale it up to a more complex UI then you may want to utilize the AJAX/Turbolinks approach, but even then you'd do almost all of your programming server side (the tiny amount of JS is just to enable the AJAX/Turbolinks).
The biggest problem with this "new" (how funny that sounds) approach is that it requires a different skillset, there are now heaps of devs familar with React etc but comparatively few strong at core HTML and CSS (I'm also looking at myself, lol). So if this approach is to become popular then we'll need to "train and relearn".
On the other hand, React (and for instance Next.js which enables SSR) when done "right" can be just fine as a dev experience but what you see is that people tend to overcomplicate stuff. Redux, redux-thunk, sagas, behavior/presentational, patterns and again patterns, I can easily see that people get "JS fatigue", we're just busy with tech and not with business problems.
Other example: people throw in moment.js and lodash/underscore adding another how many KB extra download (and parsing/compiling) where most of that can be implemented using native JS and a few wrapper functions. Way too much baggage which gets added without thought.
On the other hand, the time people are wasting at setting up Webpack and Babel and whatnot should at some point become a thing of the past, this should be a matter of running a few commands from the terminal and after that forget about it. But maybe we're not there yet.
Anyway, yes this approach feels like a breath of fresh air.
In addition to making your pages much more lightweight and taking the complexity out of web dev there's also the huge reduction in boilerplate: with API + SPA you're programming a lot of things at least 2 times (on the server, and then on the client) - validation, passing data from a to b, redundancy and duplication everywhere.
What do you think about the upcoming Web Components standard? That might make it possible to vastly improve the "native" capabilities of HTML while remaining light on JS and framework agnostic.
By the way, you didn't put the code somewhere on Github? (I can imagine that you're protecting it as you're running a business on it)
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.