In my particular case, the content is user generated, akin to reddit, so it is immediatly published.
For other cases, your solution may work, but it adds another moving part to the stack.
The reason you can have, say, gatsby, next.js, nuxt, sapper, etc, and don’t suffer from the disconnect between what the backend knows about the markup and what the frontend knows about what to enhance, is because both the browser and node can evaluate the same code(more or less, but you get the idea). With this stack it doesn’t matter if you build an SPA or not, because the client always receives all it needs to show content to the user or crawlers.
But this isn’t the case with Phoenix, so despite having an excellent templating engine, if you want to avoid the disconnect you need to spin up a node server and let it handle the frontend. You can mix them of course, but at some point you think “this would be SO MUCH EASIER(and maybe cheaper) if I could just do everthing in js”, so that’s why I think we see MPA or SPA, and not much in between(maybe github is one of those rare specimen that take the in-between route).
For some stuff, it doesn’t really matter who knows what. A dropdown or an image cropper, for instance, can be built with whatever frontend tool you want.
When you have content that needs a roundtrip to the server to perform some action and reflect the results in the client, however, it does matter and drives the way you design everything. It can be a page navigation to not lose state on some layout pieces(like a chat miniwindow), it can be a change on how certain pieces of content are displayed.
So coming back to the topic of Phoenix LiveView vs SPA, I believe this is where I think LiveView shines, because it allows you add behavior to the markup not without the need to write js, but without the need to spin an additional server to handle the frontend and without having your presentation pieces split between clientside libraries and backend templates. And I believe it’s for this very reason LiveView is coupled to the DOM and it’s not just a data diffing/syncing library. Most people don’t have the scale of github or twitter, and Phoenix channels have already proved to scale very well, so I believe LiveView can take you quite far. If you do reach a really big scale, I would say you’re making enough money to hire a bigger team and maintain more complex stacks.
I hope this makes my stance more clear. I’m not in the SPA or anti SPA team, because I understand both approaches have their places and I’ve already tried both extremes(FWIW, most of the user facing content of my project is phoenix templates intertwined with js enhancements, and the backoffice is mostly handled by js alone). But when you want to sit in the middle ground and keep your stack small, there’s a lot of dragons to tame. You can’t have the cake and eat it too, I guess. It’s a very very wide topic and there’s a lot of factors to have in mind.
I’m not using LiveView because I have some concerns about memory usage with potentially infinite data sets in the client(infinite scrolls), but it does solve real problems for a wide variety of use cases.