We take the Phoenix approach of splitting the DOM into static and dynamic parts. In fact, we even re-use the pheonix.js library on the frontend, so we just implement the backend part that speaks the same protocol as Phoenix.
I don't think that sending DOM patches directly would have a significant higher bandwidth cost, but it would have higher "implementation" cost for us. That's why we choose to just use an existing "battle tested" library.
Oh, hey that's great! So in your case, you're re-using the Phoenix client, and thus the Phoenix protocol lives on so as not to break that. Makes sense.
Thanks for the answer -- the current SDUI renaissance is a beautiful thing. Cheers :)
Didn't mean to distract from the main discussion either -- pre-emption is something that more people should want, I think, so y'all making it the default for WASM stuff feels super valuable. And surely the sandboxing is really valuable to some people too. (But day-to-day I probably won't use Lunatic, whereas LiveView-based SDUI is my current shop-time project).
I don't think that sending DOM patches directly would have a significant higher bandwidth cost, but it would have higher "implementation" cost for us. That's why we choose to just use an existing "battle tested" library.