React might make sense for some specific components wired up with hooks in Liveview for real-time interactions. So if you have a complex client side component t

React might make sense for some specific components wired up with hooks in Liveview for real-time interactions. So if you have a complex client side component that is already available in React and you don't want to recreate it - I'd just add the JS dependency to Phoenix and embed it in a view somewhere. There are definitely complex client side interactions where integration with Liveview would be preferred, however in those cases React isn't necessarily the best option - vanilla JS or D3 or something of that nature tends to be the winning ticket. TBH I wouldn't greenfield a new web app with React if I could avoid it - either wrapping a Liveview in a React component or React in a Liveview the purpose would be to gradually transition away from React running the whole DOM/view for a large existing app. A GraphQL server with Phoenix/Absinthe for a multi-platform app web + mobile (android + ios) is reasonable but still a bigger company/team solution. React + State management like Redux is a ridiculous amount of overhead by default and I would never implement a greenfield web app that way in 2021. A Liveview interaction follows something like Backend State <query/command> Liveview <websocket> Client/Browser (where only minimal diffs of changed state is sent over the wire) and React is Backend State <query/command> Controller <JSON/HTTP> Axios <Redux/State Management> Virtual DOM <> Browser/Client (where whole json payloads are sent and encoded/decoded over the wire) Where new state means re-fetching all the state each loop instead of just what changed. The amount of data sent over the wire by default is massive with this React + HTTP/JSON model. The encoding/decoding of JSON and having to send full payloads then having state management occur in multiple places and languages - it ends up being a lot more to know and think through. The lines of code to write and amount over the wire with the classic JSON over REST + React/Redux makes it almost 100% required to have separate front/backend developers which then means coordination costs for every new feature. So TLDR; React could make sense for complex components you don't want to reinvent the wheel for or when those interactions are complex and client side. Existing web apps with a lot of React code that is too much to port over all at once can be done piece by piece (where I'd recommend heading towards handling navigation in Phoenix/Liveview and components in React).