People who have worked in depth with React and SPA's - how realistic is LiveView for a replacement?

I’ve built a few apps as SPA’s using react and graphql.

Realistically, how good of a replacement is LiveView for this toolset? I remember pure MVC server-side rendered applications being much easier to work with and faster too.

Don’t know how we got here exactly but I’m kind of looking for the eject button. Is LiveView that button?

image

3 Likes

I have no experience with LiveView but our company has used ASP.NET Razor Components that is very similar tech. Biggest issue with tech like this is latency. If you are creating app that is only accessed from single country and your app is also hosted in that country at central location on fast network it should work fine for lot of web apps.

1 Like

Have only played with LiveView in a toy project so far, so pinch of salt and all that, but from what I’ve learned it mainly comes down to what level of latency is acceptable.

If you need a UI that responds with low latency, you won’t be able to guarantee that with LiveView unless you run a lot of custom code on the client side – and then what’s the point. If someone’s on a slow mobile connection, or has a slow ping to your servers, that will affect round-trip times for every interaction. Though LV does a lot to keep data payloads small.

That said, for many applications, that kind of latency is fine. If you’re filtering a search or validating a form, you likely won’t notice – and the search filtering would probably require a server roundtrip anyway, so wouldn’t be faster in React.

Optimistic UIs, like switching the state of a “Like” button are easier in React, too, of course, since the client owns those visual states and can switch them immediately and send off a request later. In LiveView, you’d either wait on a round trip, or have to maintain some custom JS (and again – if you do a lot of state management on the client, what’s the point?).

I think of those more as trade-offs than as negatives. I don’t believe LiveView aims to be a React replacement in every situation. If you’re working on something that requires a low latency UI and a lot of optimistic changes, I’m sure Chris and José would be the first to tell you to pick something like React :slight_smile:

Oh, and also – for secondary bits of interactivity like collapsing/expanding content that’s already loaded on the page, you can still use sprinkles of JS for that. Some effort has gone into ensuring LV works well together with Alpine.js, for example.

Edited to add: Offline apps are also a no-go, of course.

2 Likes

In my opinion developers are missing the point about the real use case for Live View, and that is a lot due to disservice that PhoenixPhrenzy contest made and all that useless demos out there, that use live view to build games and change the Dom for pure user interactions with the page that do not require server side business logic.

So my take in my product is that I am using Live View but I am keeping it to places where I need to change the data with business logic, aka when a trip to the back-end is always necessary no matter what technology you are using, and where I want to avoid duplication of the business logic between server side and client side, like forms validations.

For example I am not using LV to control the Dom from the server side for things that are about user interaction with the page, like a menu, modals, popups, collapse/exapnd divs, etc. because that is what I see being done a lot. For that developers I just recommend them to use whatever they are building when commuting by train, bus or car and observe how sluggish the webpage will become.

26 Likes