I'm surprised this wasn't about WASM.
Either way, I'm receptive to the "LiveView" model, but until such a time a server can deliver both HTML and server driven native UI for mobile interchangeably, I prefer the RPC approach.
I don't want to develop:
1. Both an API for mobile and LiveView for web.
OR
2. Create my own server driven UI paradigm for mobile.
I find maintaining one architectural pattern simpler. I do want to support users with the best technology fit, but I don't see why I have to make this tradeoff. The platform holders are (and always have been) jerking us around.
I want to see a LiveView that can deliver both HTML and equivalent native UI markup. This is needed to sell the vision end to end - the world is not just web.
I feel like this would enable a more sensible choice:
Offline (first)? Use RPC with sync.
Online-only? Use the LiveView paradigm and it'll work with native or web.
Either way, I'm receptive to the "LiveView" model, but until such a time a server can deliver both HTML and server driven native UI for mobile interchangeably, I prefer the RPC approach.
I don't want to develop:
1. Both an API for mobile and LiveView for web.
OR
2. Create my own server driven UI paradigm for mobile.
I find maintaining one architectural pattern simpler. I do want to support users with the best technology fit, but I don't see why I have to make this tradeoff. The platform holders are (and always have been) jerking us around.
I want to see a LiveView that can deliver both HTML and equivalent native UI markup. This is needed to sell the vision end to end - the world is not just web.
I feel like this would enable a more sensible choice:
Offline (first)? Use RPC with sync.
Online-only? Use the LiveView paradigm and it'll work with native or web.