I think the emphasis on SEO, and it being an argument against using an SPA is not at all universal.
Depending on the target audience for the application, I.E a business app vs something like twitter, github or a forum…SEO is not really important. If the app is behind a login page, sacrificing UX for the sake of SEO is not really defensible.
That is the purpose of a marketing site, which promotes the features, and problems your app is trying to solve. The marketing site will be completely static, and have the SEO nobs dialed to the max, with a link to login to the actual app.
In my case, this is pretty much 100% of what I build…so moving rendering to the server for anything but improving metrics like Largest Contentful Paint is only costing the business compute - as mentioned before, client side rendering is free distributed computing…
And if you think the app you are building is going to be Twitter, GitHub scale, and actually see meaningful organic growth from SEO - you are already a bit of a unicorn, imho.
One way I have dodged the slow paint and abrupt rendering of an SPA is to apply some full page inline CSS animation on the served HTML. Allowing the browser to immediately show some indeterminate loading screen. This is pretty common for say a desktop/mobile application to require a loading screen or indicator before actually launching - I do not think this is bad UX, and actually expected if the App has enough data/interactivity…
EDIT: Also, pretty sure LiveView would not work that great for an App like Twitter, or GitHub - or at least at that scale. So say you did build the next Socially Responsible Twitter
with LiveView - wonder how the engineering would evolve…I imagine the thought of an SPA would come up in the board room because the servers are starting to cost a bit too much. This same argument applies to the Redex library I have posted about - there is definitely a threshold of scale that likely means server side in memory state is a bad idea…