Garrison 
you share the same feelings towards streams as me. You can check my point in this post. I like to think I had some influence over adding :key into loops 
All in all, I’ve done some testing and while that’s definitely an improvement, they’re not fully there, yet.
Anyway, I mostly avoiding streams now. IMO state should be either client-side, or server side. If I want ephemeral state on the client, I’m usually using {:reply, value, socket} tuple from handle_event, which then acts as an “API endpoint” of sorts. Having a full-blown client framework on the client side greatly helps with it, so I can decide what to do with that response.
In LiveVue I’m experimenting with using Jsonpatch.diff for each updated prop to minimize payload size at the expense of some processing time. This will remove a “smaller payload” argument from using streams. Optimizing memory footprint sounds important, but personally I’ve never had a serious issue with it.
Some random rambling:
- Optimizing rendering & payload diff of LiveView is almost exactly the same as optimizing number of HTML updates with virtual DOM in a modern framework. Just, that virtual DOM tree is on the server, and not on the client.
- Thus, almost all techniques used in eg React or Vue should make sense. :key in loops, change tracking, dynamic vs static content etc.
- Would be great to have a build-in way of declarative client-side rendering. Alpine JS / Vue Petite are nice, just not really enough. Hologram is interesting, but I’m worried it will try to “reinvent the wheel” instead of making it possible to use existing solutions from the frontend world.
Anyway, that’s that for now 
