[porker]

> And Phoenix LiveView (not released yet), which I personally think pulls the strengths of Phoenix together in a way that can truly disrupt web development. It’s very difficult to do what LiveView is doing on other tech stacks.

LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy.

And unless you replicate to many locations, or can deploy it to edge compute nodes (no idea) then this will always be a problem compared to 'true' client-side development.

I want it to work but I don't see how it can beat the laws of physics.

[nickjj]

> LiveView cannot avoid latency. When I've experimented it's great for something running on my local network; less good when it's in a datacentre in another country. It's laggy.

If you built a traditional SPA, aren't you still making loads of calls to your server?

I don't see how LiveView would be more laggy than that. In both cases you're making network calls from the user's machine, to your server, getting a response from the server and then rendering output on the client when it's received.

Of course you can cheat and do optimistic rendering on the client (like outputting what you wrote instantly in some DOM element instead of waiting for a response and validating it after the fact) but I believe that enhancement could be done with both techs.

The only place where LiveView falls short is a true offline / fully client side app, but those are such a rare breed and way out of the norm for a typical web app. In 20 years of web dev as a freelancer, I've been asked 0 times to build an offline / client side JS app.

[porker]

> If you built a traditional SPA, aren't you still making loads of calls to your server?

For data loading, yes. But here's a few random thoughts:

* I can pre-emptively load data in a SPA (think: 3 screens-worth of a datagrid) and keep fetching in advance, so the user rarely feels the lag.

* Much of my investigation has been around adaptive forms, wizards, validation and keeping logic in a single place. Having to define models and logic once, rather than client-side and server-side would save so much time.

My testing suggested that client-side validation still gave better results, because it was instant. Moving forward & back through a wizard was better if client-side rather than each screen rendered server-side.

I experimented early May so am a little hazy on details (and can't find which PIM I put my notes in, sigh) and look forward to seeing other people's experiments. Particularly when not run on their local machine.

[nickjj]

> My testing suggested that client-side validation still gave better results, because it was instant.

In some cases yes, but I don't think you can get away with client side validation for a lot of things because they depend on the state of your database to return the correct result.

For example, how would you validate an email or username on the client when the availability of the name depends on you making a database call to see if a user exists already? You have to make a network call, get the result and then update your validation errors on the client based on that server side result.

But for validating something like a phone number or twitter handle, sure, client side works all the way but I don't think having even 200ms of delay for that validation is going to make for a bad user experience. 200ms is a lot too. That's about what it takes to ping a server in Tokyo from New York.

Your other points are valid tho. I guess we'll see where LiveView ends up going.

[rikkus]

LiveView was always going to have this limitation. Its design makes it suitable for low latency links - such as local network.

It’s not going to fail to ‘work’ because of this. It just has a niche and isn’t a general purpose web framework.

I’m looking forward to building some admin tools with it, reducing the complexity required when having to deal with server and client separately.

[porker]

> LiveView was always going to have this limitation. Its design makes it suitable for low latency links - such as local network. [...] I’m looking forward to building some admin tools with it

All our tools are now hosted in the cloud - we don't run any servers on the local network. With a 20-30ms RTT perhaps it will feel smooth - or the micro-delays will be noticeable.

[markkanof]

That's a fair point, but it does seem like a solvable problem. There are multiple companies offering gaming services where the game is running on a remote system. I haven't tried any of these services, but from what I hear they are very useable for casual games, but still have some work to do for FPS type games where milliseconds count. That would indicate to me that getting a web UI to work with this type of setup should be very possible with geographically distributed servers.