If you mean on the same page, I would think that react and liveview would collide, and to solve it you would have to wire react to reload each time the html was overwritten.
If you did not mean on the same page, you are not limited to any of them. You can have both serverside rendered (ssr) pages, ssr pages with LiveView, and pages with react.
@malloryerik - though LiveView doesn’t fit nicely with client side frameworks that render HTML, I’ve also been looking for a sort of middle-ground where I can still use my React components. I came up with something similar to LiveView that renders JSON instead of HTML. On the client side, it takes the JSON output + a function to update and wraps it in a React Provider. Then my other components can use a React Consumer to access the data and update it. It’s basically a very poor man’s server-side redux. It’s a PoC at this point, but I’d love to get any thoughts/feedback.
Thanks!
Drab, however, supports more things, such as interactions with API’s on the frontend and more. Live seems more like Drab’s living assigns things and controlling/owning the entire DOM, so Drab definitely still has a place! 
This is true, actually Drab is quite mature, because it’s been born in the long discussions in this forum.
exec_js(socket, "2+2"))So after reconsideration I am going to move Drab to the v1.0, as it is just a few steps ahead, and a lot of code for this is already done. I hate wasting good code. The project will be supported (bug fixes) as long as people are using it, but no new big features will be developed by now (sorry @OvermindDL1, no token via cookie, as I want to wait to see how Chris will cover this, but we may think about building our own transport as it would be easier since phx1.4).
Then I will take a break and will see what will born as a LiveView. If, as I assume, it will be a huge success, I will give up Drab.Live and Commanders and adopt rest of the Drab features to the LiveView, using its event handler API (phx-click attributes). Which accually I like more than mine, I probably overcomplicated stuff with Commanders, but have some concerns if it can cover some cases.
Well I’m definitely making a lot of use of Drab for sure. ^.^
I still like commanders, makes it easy to make reuseable little widgets (like a notification widget for example) on many pages but that commander just controls that tiny section of it.
I’m not sure I want redux on the server. Servers have been handling state without such patterns with great productivity for a long time. I can only speak to the texas impl. but state is not something texas cares about because server-side is already great with tons of solutions for handling state.
I think texas can do the “smart diff” on nested dynamic templates - I’m not familiar enough with liveview to speak to it, but with texas all you’d have to do is attach an id to the dynamically generated “partial/component/whatever”
For instance <div data-texas="conversation" data-texas-id="123"> ... </div> could be generated dynamically and the only thing you would have to do with texas is broadcast a message that looks something like "conversation:123" (psuedocode, not real impl) and subscribers to that message could then call a view rendering function that pattern matches to see if an texas-is was given, if so, only render out the dynamically generated partial/component for the given id
edit: update with example
Oh, totally. I meant to say that we can’t do smart diffs with .eex (or a subset thereof) unless we introduce parsing + some restrictions which I assume would put us somewhere close to .tex.
makes sense, sorry I’m glossing through all these conversation and I’m late to the party so I probably missed that context