3 ms·

I personally think the future is adding live functionality to the server, like how Phoenix does with LiveView.

by lawn 4y ago

Existenceblinks 4y ago
I used Liveview before (on very early version), now I use PhoenixChannel and javascript, it's great balance.
- nagasadhu 4y ago
  Same here. Mixing ui and data logic layer was not pretty. Alpine js didn't cut it for me.
  - Existenceblinks 4y ago
    Also there is a transformation on js before handing diffs to Morphdom. There was no "replace the whole thing" without having to perform recursive diffs back then, not sure if it has now.
chrismorgan 4y ago
The rather massive weakness of that approach is that it requires a functioning internet connection to do anything, and is badly affected by latency. If you lived on the other side of the world from the server and had a sometimes-unreliable or -unavailable internet connection, you would not sing LiveView’s praises so loudly.
- sfusato 4y ago
  You should be using LiveView only for things that would require a server trip anyway. For client side interactions, use a client side JS library (like Alpine [1] if Phoenix.LiveView.JS [2] is not enough) [1] https://alpinejs.dev/ https://alpinejs.dev/ [2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...
  - chrismorgan 4y ago
    The problem is that LiveView forces synchronous operation, whereas a significant fraction of things that would require a server trip anyway could actually be done asynchronously—that is, as far as the UI is concerned, they actually don’t require a server trip; not immediately, anyway, and the UI should only care about the immediate. When you control server interactions on the client side, you can do things like optimistic editing, where the UI assumes the action will succeed and then does it in the background, and then handles the exceptional case where something goes wrong, most likely by returning you to a form; or things like queuing actions up when there’s no internet connection, and performing them when you get a connection again. I want to emphasise again the importance of latency. I live in Australia. Most of the web is much slower in Australia than it is in the USA, not because of bandwidth, but because of latency. The LiveView approach is convenient, but it’s technically not a good solution for most applications. It’s excellent for things like chat systems where being bound to synchronous operation and requiring a network connection to do things isn’t an issue, but I honestly don’t think it’s the best solution (technically, again; socially it may be) for much else.
- sph 4y ago
  How many apps have you written that should work offline? Because in my career it might have been less than 5% of projects. It's fine to optimize for the remaining 95%. My client's CRUD app doesn't need an offline mode. It would be nice, sure, for that one time the boss is using the app on a plane, but it's towards the bottom of the priority list. 95% of projects, I'd pick productivity over working offline, especially these days when being truly offline is more and more rare. And lastly, even in JS, offline support is a pain in the arse, not a given. You have to design your entire app around it, it's not something you can add 2 days before shipping.
  - chrismorgan 4y ago
    The trouble with the thin client approach is that fundamentally no control is possible on the client-side. Since the connection from client to server is unreliable, this renders such pages unnecessarily fragile, considerably more fragile than traditional server-generated pages with conventional navigation by link and form. Really, I’d say that in most places where people are inclined to use the thin client approach, they’d be better served by traditional server-generated pages with no overriding of client-side routing or other such fancy scripting. Have you experienced this type of thin client when you have half a second’s latency, or a connection that keeps dropping out, or moderately high packet loss? I don’t think I’ve actually encountered a full thin client in the wild, but from my experiences with other poorly-done (very common) network-bound web apps in such circumstances, I can report that things are considerably worse than one would expect—that half a second’s latency inexplicably leads to things taking several seconds instead of fifty milliseconds a lot of the time (though I will admit that a pure thin client is less likely to find this so); and that very brief dropout manages to lock the page up for ten or thirty seconds until it manages to (or decides to) reconnect, or just breaks your page completely so that you have to restart and lose progress. I have worked on apps that work offline or partially-offline, but the problems of the thin client approach are so much more than that—which is why I didn’t use the word “offline” in my earlier comment. Prefetching. Caching accessed entities so that you can revisit them without talking to the server. The bfcache, once you’re talking about simple pages rather than apps. And various more things, some of which I spoke of in my other comment here. The thin client approach is a nice idea. It can be suitable for tightly controlled deployments. It can be suitable for a very restricted set of apps. It can be a pragmatic choice sometimes. It will tend to be better than a badly-done client-side-rendered app. But I am convinced that it is not very often the best choice, taking into account both user and business considerations; and that for consumer systems, it’s rarely a good choice.

I personally think the future is adding live functionality to the server, like how Phoenix does with LiveView.

by lawn 4y ago

I personally think the future is adding live functionality to the server, like how Phoenix does with LiveView.

Existenceblinks 4y ago

I used Liveview before (on very early version), now I use PhoenixChannel and javascript, it's great balance.

nagasadhu 4y ago
Same here. Mixing ui and data logic layer was not pretty. Alpine js didn't cut it for me.
- Existenceblinks 4y ago
  Also there is a transformation on js before handing diffs to Morphdom. There was no "replace the whole thing" without having to perform recursive diffs back then, not sure if it has now.

chrismorgan 4y ago

The rather massive weakness of that approach is that it requires a functioning internet connection to do anything, and is badly affected by latency. If you lived on the other side of the world from the server and had a sometimes-unreliable or -unavailable internet connection, you would not sing LiveView’s praises so loudly.

sfusato 4y ago
You should be using LiveView only for things that would require a server trip anyway. For client side interactions, use a client side JS library (like Alpine [1] if Phoenix.LiveView.JS [2] is not enough) [1] https://alpinejs.dev/ https://alpinejs.dev/ [2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.html https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...
- chrismorgan 4y ago
  The problem is that LiveView forces synchronous operation, whereas a significant fraction of things that would require a server trip anyway could actually be done asynchronously—that is, as far as the UI is concerned, they actually don’t require a server trip; not immediately, anyway, and the UI should only care about the immediate. When you control server interactions on the client side, you can do things like optimistic editing, where the UI assumes the action will succeed and then does it in the background, and then handles the exceptional case where something goes wrong, most likely by returning you to a form; or things like queuing actions up when there’s no internet connection, and performing them when you get a connection again. I want to emphasise again the importance of latency. I live in Australia. Most of the web is much slower in Australia than it is in the USA, not because of bandwidth, but because of latency. The LiveView approach is convenient, but it’s technically not a good solution for most applications. It’s excellent for things like chat systems where being bound to synchronous operation and requiring a network connection to do things isn’t an issue, but I honestly don’t think it’s the best solution (technically, again; socially it may be) for much else.
sph 4y ago
How many apps have you written that should work offline? Because in my career it might have been less than 5% of projects. It's fine to optimize for the remaining 95%. My client's CRUD app doesn't need an offline mode. It would be nice, sure, for that one time the boss is using the app on a plane, but it's towards the bottom of the priority list. 95% of projects, I'd pick productivity over working offline, especially these days when being truly offline is more and more rare. And lastly, even in JS, offline support is a pain in the arse, not a given. You have to design your entire app around it, it's not something you can add 2 days before shipping.
- chrismorgan 4y ago
  The trouble with the thin client approach is that fundamentally no control is possible on the client-side. Since the connection from client to server is unreliable, this renders such pages unnecessarily fragile, considerably more fragile than traditional server-generated pages with conventional navigation by link and form. Really, I’d say that in most places where people are inclined to use the thin client approach, they’d be better served by traditional server-generated pages with no overriding of client-side routing or other such fancy scripting. Have you experienced this type of thin client when you have half a second’s latency, or a connection that keeps dropping out, or moderately high packet loss? I don’t think I’ve actually encountered a full thin client in the wild, but from my experiences with other poorly-done (very common) network-bound web apps in such circumstances, I can report that things are considerably worse than one would expect—that half a second’s latency inexplicably leads to things taking several seconds instead of fifty milliseconds a lot of the time (though I will admit that a pure thin client is less likely to find this so); and that very brief dropout manages to lock the page up for ten or thirty seconds until it manages to (or decides to) reconnect, or just breaks your page completely so that you have to restart and lose progress. I have worked on apps that work offline or partially-offline, but the problems of the thin client approach are so much more than that—which is why I didn’t use the word “offline” in my earlier comment. Prefetching. Caching accessed entities so that you can revisit them without talking to the server. The bfcache, once you’re talking about simple pages rather than apps. And various more things, some of which I spoke of in my other comment here. The thin client approach is a nice idea. It can be suitable for tightly controlled deployments. It can be suitable for a very restricted set of apps. It can be a pragmatic choice sometimes. It will tend to be better than a badly-done client-side-rendered app. But I am convinced that it is not very often the best choice, taking into account both user and business considerations; and that for consumer systems, it’s rarely a good choice.