4 ms·

Maybe I'm missing something here (tell me), but after being initially amazed by the architectural concepts, I tried demos of a similar tool (https://docs.stimul

Maybe I'm missing something here (tell me), but after being initially amazed by the architectural concepts, I tried demos of a similar tool (https://docs.stimulusreflex.com/ https://docs.stimulusreflex.com/) and was eventually disappointed by the result. Why? Because the resulting UX is not comparable with a SPA at all. With a SPA, you instantly get a visual response when you click something (even if this response is a spinner) while with this kind of tool, there is a small bu weird delay (because of websockets) that makes the whole experience laggy, and pretty weird to me, especially after being used to SPAs. I totally understand that the balance between the tasks to achieve and the end result is very good, but this techno does not look like a replacement of SPAs to me.

nlitened 5y ago
I tried the demos (e.g. https://expo.stimulusreflex.com/demos/todo https://expo.stimulusreflex.com/demos/todo), and indeed they feel laggy. On the other hand, I think it is a failure of the UI, but not of the whole LiveView concept. UI elements could get an automatic visual indication of being "in progress" on the client side after being clicked, and I believe the feeling of lagginess should go away.
- tluyben2 5y ago
  While I agree with that, I do not understand why this is quite so laggy. As we have different people here try and they all say it's laggy, irrespective of location (we are probably not all sitting in Portugal) and internet quality (maybe we all have slow internet though), there seems to be something wrong. But yes, add a spinner to indicate server communication and suddenly it'll look quite normal. SPA's that don't do that, with my connection, I often see the item appear but then get a server communication timeout after that which is, well, equal or worse to this.
  - jkmcf 5y ago
    It's a demo server? Go try Hey.com. Their email approach doesn't work for me, but the native app uses stimulus and it feels (felt? it's been a year) snappy.
    - kawsper 5y ago
      Hey uses Hotwire (which Stimulus is a part of) they do not use Stimulus Reflex.
out_of_protocol 5y ago
1) The only issue here is network latency, and if you're not crossing half of the world it is not that high (elixir/liveview itself does not take much time - like single digit milliseconds, maybe less) 2) it's possible to combine both approaches, using bits of javascript to fill in client-only animations etc.
seehafer 5y ago
We heavily debated going with StimulusReflex instead of LiveView because of the team’s existing familiarity with Rails. In our experience StimulusReflex doesn’t work because Rails isn’t fast enough. Phoenix is.
bluewalt 5y ago
You're probably right. I'd like to see a demo of a something like https://todomvc.com/ https://todomvc.com/ made with it, and compare the feeling between a SPA and LiveView.
rkangel 5y ago
Normal HTTP request latency is much better in Phoenix that in Rails. You can't do much about the intervening network latency but I'd expect a LiveView app to be snappier. Good practice seems to be the PETAL stack (https://thinkingelixir.com/petal-stack-in-elixir/ https://thinkingelixir.com/petal-stack-in-elixir/) using Alpine.js to sprinkling in some client side UI stuff that doesn't need to go via the server. LiveView isn't intended to replace SPAs. If you have a lot of UI interaction where the UI changes "shape" in response to user interaction then no you probably want JS. For a lot of things people are doing they don't need that though. Implementing a form in LiveView is a use case that completely shines. You implement all your validation once on the server and use that same validation code (the ecto changeset stuff) to do your live UI messages in the client. It also doesn't matter if it takes 100ms for the text box to go red and say "password too short" in that use case. You can get a 'live' friendly and helpful interactive form with all the user feedback you want and it costs you barely more than the effort to do just the server side stuff, and without any risk of mismatching validation.
chrismccord 5y ago
Phoenix creator here. Stimulus Reflex and most LiveView-like solutions do not perform diffing that LiveView does, so you are receiving the entire page/template for every change which adds to the overhead. You are correct that purely client-side interactions should be instant, and we promote keeping purely client-side interactions client-side. For any interaction that must otherwise make a trip to the server – saving a form, posting a message, fetching new results, etc, an SPA will not be any better. In fact, it will usually be slower because LiveView payloads are going to be better optimized than the best hand written JSON you could write for your SPA client/server contract. Likewise, we use the established websocket connection so there is no HTTP handshake, header parsing, authentication, etc for every interaction so LiveView can provide a better UX when round-trips are involved than SPAs. For client-side interactions, we have a number of UI features built-in that provide user feedback while awaiting an acknowledgment and tools like Alpine.js are fantastic when you have purely client-side interactions to perform like opening navs and controlled input formatting. I wrote about UX considerations with LiveView here that addresses these points: https://dockyard.com/blog/2020/12/21/optimizing-user-experience-with-liveview https://dockyard.com/blog/2020/12/21/optimizing-user-experie...
- bluewalt 5y ago
  Thanks for the explanations. This makes perfect sense that having an open WebSocket connection drastically speed up the exchanges between client and server. However, I guess there is still a UX difference with SPAs when you go to a new page. Going to another page with a SPA is instantaneous, and user just waits for server-side data to be loaded, with data with spinners in between. But with Liveview, the client would need to wait for the server to render the whole new page, before displaying anything new (exactly like a standard MVC framework). And this specific behaviour can create a "laggy feeling" IMO. This will never be as fast as a SPA in this case. I think this can be disturbing, especially for websites used as mobile apps. In that case, users expect navigating between app pages without waiting at all, even if they are used to to wait for specific data to be loaded in that same page. Please correct me if I'm wrong, but to me, it seems Liveview is perfectly suited for intensive data exchange on an open page (for example, the bitcoin example used in this video seems perfect), but not suited for apps with an intensive navigation between different pages, because that pages will require a round trip to the server to be rendered. Still, I'm jealous there is no Liveview equivalent in Python, so that I would stop requiring the whole SPA toolchain as soon as I need some updates in my project.

nlitened 5y ago

I tried the demos (e.g. https://expo.stimulusreflex.com/demos/todo https://expo.stimulusreflex.com/demos/todo), and indeed they feel laggy. On the other hand, I think it is a failure of the UI, but not of the whole LiveView concept. UI elements could get an automatic visual indication of being "in progress" on the client side after being clicked, and I believe the feeling of lagginess should go away.

tluyben2 5y ago
While I agree with that, I do not understand why this is quite so laggy. As we have different people here try and they all say it's laggy, irrespective of location (we are probably not all sitting in Portugal) and internet quality (maybe we all have slow internet though), there seems to be something wrong. But yes, add a spinner to indicate server communication and suddenly it'll look quite normal. SPA's that don't do that, with my connection, I often see the item appear but then get a server communication timeout after that which is, well, equal or worse to this.
- jkmcf 5y ago
  It's a demo server? Go try Hey.com. Their email approach doesn't work for me, but the native app uses stimulus and it feels (felt? it's been a year) snappy.
  - kawsper 5y ago
    Hey uses Hotwire (which Stimulus is a part of) they do not use Stimulus Reflex.

out_of_protocol 5y ago

1) The only issue here is network latency, and if you're not crossing half of the world it is not that high (elixir/liveview itself does not take much time - like single digit milliseconds, maybe less) 2) it's possible to combine both approaches, using bits of javascript to fill in client-only animations etc.

seehafer 5y ago

We heavily debated going with StimulusReflex instead of LiveView because of the team’s existing familiarity with Rails. In our experience StimulusReflex doesn’t work because Rails isn’t fast enough. Phoenix is.

bluewalt 5y ago

You're probably right. I'd like to see a demo of a something like https://todomvc.com/ https://todomvc.com/ made with it, and compare the feeling between a SPA and LiveView.

rkangel 5y ago

Normal HTTP request latency is much better in Phoenix that in Rails. You can't do much about the intervening network latency but I'd expect a LiveView app to be snappier. Good practice seems to be the PETAL stack (https://thinkingelixir.com/petal-stack-in-elixir/ https://thinkingelixir.com/petal-stack-in-elixir/) using Alpine.js to sprinkling in some client side UI stuff that doesn't need to go via the server. LiveView isn't intended to replace SPAs. If you have a lot of UI interaction where the UI changes "shape" in response to user interaction then no you probably want JS. For a lot of things people are doing they don't need that though. Implementing a form in LiveView is a use case that completely shines. You implement all your validation once on the server and use that same validation code (the ecto changeset stuff) to do your live UI messages in the client. It also doesn't matter if it takes 100ms for the text box to go red and say "password too short" in that use case. You can get a 'live' friendly and helpful interactive form with all the user feedback you want and it costs you barely more than the effort to do just the server side stuff, and without any risk of mismatching validation.

chrismccord 5y ago

Phoenix creator here. Stimulus Reflex and most LiveView-like solutions do not perform diffing that LiveView does, so you are receiving the entire page/template for every change which adds to the overhead. You are correct that purely client-side interactions should be instant, and we promote keeping purely client-side interactions client-side. For any interaction that must otherwise make a trip to the server – saving a form, posting a message, fetching new results, etc, an SPA will not be any better. In fact, it will usually be slower because LiveView payloads are going to be better optimized than the best hand written JSON you could write for your SPA client/server contract. Likewise, we use the established websocket connection so there is no HTTP handshake, header parsing, authentication, etc for every interaction so LiveView can provide a better UX when round-trips are involved than SPAs. For client-side interactions, we have a number of UI features built-in that provide user feedback while awaiting an acknowledgment and tools like Alpine.js are fantastic when you have purely client-side interactions to perform like opening navs and controlled input formatting. I wrote about UX considerations with LiveView here that addresses these points: https://dockyard.com/blog/2020/12/21/optimizing-user-experience-with-liveview https://dockyard.com/blog/2020/12/21/optimizing-user-experie...

bluewalt 5y ago
Thanks for the explanations. This makes perfect sense that having an open WebSocket connection drastically speed up the exchanges between client and server. However, I guess there is still a UX difference with SPAs when you go to a new page. Going to another page with a SPA is instantaneous, and user just waits for server-side data to be loaded, with data with spinners in between. But with Liveview, the client would need to wait for the server to render the whole new page, before displaying anything new (exactly like a standard MVC framework). And this specific behaviour can create a "laggy feeling" IMO. This will never be as fast as a SPA in this case. I think this can be disturbing, especially for websites used as mobile apps. In that case, users expect navigating between app pages without waiting at all, even if they are used to to wait for specific data to be loaded in that same page. Please correct me if I'm wrong, but to me, it seems Liveview is perfectly suited for intensive data exchange on an open page (for example, the bitcoin example used in this video seems perfect), but not suited for apps with an intensive navigation between different pages, because that pages will require a round trip to the server to be rendered. Still, I'm jealous there is no Liveview equivalent in Python, so that I would stop requiring the whole SPA toolchain as soon as I need some updates in my project.