React or Phoenix liveview. Frontend usecase

jinder

Hi all,
I am new to Phoenix with small frontend experience. I have a usecase where I am curious to know how you would approach the following:

Use Case : Need to render data in table where rows can be sorted again column in acs and des. order of values. Sorting happens for the current rendered rows.
Since the sorting is straightforward, should it be handled by liveview handle_event or directly handle on frontend using component like material-ui react table . I am using react for frontend. Would there be any advantage of liveview over react in such case ?

5 comments

/phoenix #react #liveview #reactjs

0 1937 5

2025-04-22 10:24:54 UTC

Showing Posts 1 to 5

Show Best Posts
Show All (oldest first)
Show All (newest first)

tfwright

Most of the power of live view comes from keeping state on the server and rendering markup there. Rendering a table is an extremely common use case. I would only even contemplate dealing with react if I had to build a front end for a backend I dont control.

Post #1

kanishka

Not that I can tell.

My limited understanding of the advantage of liveview is that you don’t have to implement an API and your full stack devs can focus on one programming language. If you are dealing with basic data entry/crud UIs for an early startup or small company with limited resources this can provide a boost in productivity.

Post #2

lerosbif

2 years later, is there any update to the when and why to use React over LiveView for a frontend in Phoenix?

As a learning exercise. I spent some time wiring up React to Phoenix, and in the end, I am left pondering the ‘why’ in all of this. Are there things that LiveView cannot do as well as React?

Post #3

garrison

The obvious things are offline/local-first and e2e encryption. There are also some latency advantages for a client-rendered app but the difference is very domain-specific in practice because most React apps are hitting the server for API calls constantly anyway and the distance to the database matters much more than the distance to the server.

There are some advantages for client rendering in terms of performance for some use-cases but LiveView apps can be optimized to perform better than you would probably think and React optimization is not trivial either.

LiveView apps are stateful on the server so (and this is implementation specific) they may be more expensive to operate than a client-rendered app. In practice I don’t think this is very meaningful unless you are operating at astronomical scale with thin margins - servers are cheap and Elixir scales out.

If you want the best possible user experience I still think client rendering will always win, but it’s important to understand that LiveView has a declarative stateful rendering model (like React) but on the server. This is fundamentally different from other approaches like HTMX, LiveWire, etc. It is actually possible to build extremely complex interfaces in LiveView (unlike those others), and the advantage for client rendering with respect to the average web developer is very small. The vast majority of web devs will never even get a chance to work on an app where there is a substantial difference IMO, at least if the current state of the industry holds.

I’m referring to apps like Linear or Figma here.

Finally there are a handful of use-cases for which I suspect server-rendering is actually optimal, which may be surprising. These are cases where the state is inherently biased towards the server. I think a good canonical example of this is something like the AWS console - everything is inherently server-side, and the UI is just a thin client over those APIs. I suspect that AI/Agentic apps will fall into this category once people figure out how to actually build them - a good example would be the Deep Research paradigm, where again everything is happening on the server essentially by definition.

Post #4