On the whole - it's a huge productivity booster.
Which illustrates a general problem with these kind of libraries - you need to put in a lot of effort to make them work as well as normal old old web applications. Is the performance improvement actually there, and is it worth the extra bugs and effort?
Not to pick on you either. E.g. GitHub had broken back button behavior with their turbolinks for the longest time.
Wouldn't an old old web application exhibit this behavior too?
I do think SPA's still have their usecase for when it comes to complex screens but I would like to see that screen only have the incremental complexity on it. Svelte would be my goto for that page at the moment.
It's a bit like what HEY done with their mobile app, most of the app is SSR HTML but the main inbox screen calls out to the JSON API with a native screen.
I say all this but I do love the component nature of frontend frameworks, it is nice to put things in boxes like that and have pulled in data change the view in reaction. But this new hotwire turbo frame idea sounds again much simpler where say we have a chart we want to update over time and display, in SPA world we would speak to some API change some context/store/component prop etc and let the rerender happen. With a turboframe we just make a call out to get the new updated HTML from an endpoint.
I would love some examples of people comparing and contrasting the exact same webpages + functionality with SSR + Hotwire vs SPA. Take this page for example https://nomadlist.com/ its just PHP SSR but on my initial viewing I would think this warrants a SPA.