So there are a couple important differences but some of the concerns are indeed shared.
One of the major differences is that LiveView is not trying to reinvent the wheel on the UI side of things. LiveView is not “UI running on the server”, it is not about accessing the DOM from the server, nor it requires a special client side notation. In LiveView, the server simply emits HTML and the LiveView state is not intrinsically tied to the UI in anyway.
This is an oversimplification but you can consider the previous approaches are closer to the MVC client-side framework side of things (i.e. with UI elements modelling the state) while LiveView is more on the React/Redux side of things (i.e. you keep the state on its own and use it to drive changes in the UI).
You also mentioned websockets and processes, which can lead to better performance, but the main importance of websockets is that a persistent connections implies you don’t need a storage for the “component state”. For example, if JSF uses AJAX, it means that every AJAX request can go to a different server, so you need to either persist the state in a shared storage or route requests through a cluster, both leading to overhead.
However, having a different model does not necessarily imply we won’t run into same limitations. One of the Hacker News comments posed a very good list of questions which I will try to answer below:
- Freezes and needing a refresh/logout after the server-side “actor” or connection fails.
- Refresh won’t actually work, you need to login again.
LiveView does not intend to fully replace your stateless actions. While you could do the login through LiveView and keep it as part of the connection state, that would indeed be a horrible idea! LiveView does not force you in anyway to drive all actions through the “actor”.
- Neither does back/forward, hence the big warnings not to hit back button, for example in a paginated list. Hitting back makes it freeze.
This is currently a limitation in LiveView. For example, if you have a paginated table and you are traversing the paginated table with LiveView, then you won’t have the back/forward buttons, you won’t be able to link to page 10, etc. We are aware of this and it is in the ROADMAP to provide tools to allow this. This is similar to SPA/JavaScript apps that do not leverage pushState accordingly. It can be addressed in JS and it will be addressable in LiveView too.
- Extreme latency.
I talked about this elsewhere but:
i. If you are using LiveView for things that can be addressed with CSS animations or do not involve the server at all (such as opening a menu), then yes, you are introducing latency when you wouldn’t have any latency before. But as said above, LiveView is not trying to hijack your UI in anyway, nor is it trying to replace HTML+CSS+JS.
ii. On the other hand, for applications with moderate latency, there is a chance that LiveView can reduce the amount of data sent over the wire thanks to the diff-tracking mechanism (and the upcoming binary serializer) and maybe even reduce latency altogether. For example, with a regular AJAX request, you have to do a HTTP request, then authenticate that request on the server, load the data from the database, etc. With LiveView, you have an established connection, so you skip the authentication and a lot of the data-loading on every action, so for a moderate latency, the application may be more responsive because there is generally less work to be done. This would of course have to be measured but it is a point worth considering.
iii. Finally, I think LiveView is in a very good position to tackle Optimistic UIs because any change that you do after a client action, such as clicking a button, will be undone on the next LiveView update. So it is straight-forward to do something like: click a button and enter into a loading state and the loading state is automatically undone when the update arrives. So we can provide feedback to the user on the client side as we wait for a reply and we will put more emphasis on those transitions as we move forward. And this feedback is important when latency is involved.
- No shareable urls or hyperlinks possible, two tabs in same browser will sync with each other.
About no shareable URLs, this is true for actions happening inside LiveView, such as in the paginated table, but solving this is part of the roadmap and remember that LiveView does not force all actions to go through the LiveView “actor”.
And two tabs in the same browser won’t sync with each other. Each LiveView session is distinct.
