I disagree. I’ve spent a good time reverse-engineering LiveView. Quantity != quality. Just because a lot of the logic is presentation layer oriented, does not mean that the remaining 10% (or whatever it is) isn’t powerful in itself. In-fact, that’s the part I think is most valuable and should be expanded upon to expose a front-end API (not just hooks).
But to be clear, I’m not suggesting LiveView send more data from the server to the client. Rather, you can take the data already being sent (probably even less), and decouple how it is presented to allow for more powerful UI layers (eg. shadowdom / reactive implementations that tie into advanced UI libraries like Material).
Even if morphdom was the best thing since sliced bread, the evolution of JS libraries over the past decade has shown adoption correlates to the library’s ability to be incremental. If you have a shadowdom / reactive app, it’s quite messy to throw in some morphdom into that. It’d be much better to allow UI developers the option to build their own presentation layer on the LiveView protocol.
That’s all just my opinion, but my prediction is a lot of unnecessary friction / resistance to LiveView until there’s a way to make it less mutually exclusive. Even the title of this thread “LiveView vs SPA” exemplifies the problem; which could be rewritten as “How much LiveView in my SPA?”.
