8 ms·

> Specially now we are using all the hotwire stuff. Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view?

> Specially now we are using all the hotwire stuff. Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view? I do agree that some of the "you don't need redis" and similar are overblown (particularly claims about tasks replacing background jobs), but I think there is truth to these claims in the following sense: Particularly in Rails, Redis gets used not just as a tool, but also to manage shortcomings in the language / runtime. Eg: Hotwire. Ruby doesn't have a good way to concurrently manage stateful connections, so it has to fallback to Redis. Ruby doesn't have a good way to manage inter-process or inter-node communication, so once again Redis steps in to fill that gap. There's nothing wrong with using Redis, it's a fantastic tool. Using it as a state holder for an event loop through ends up feeling extremely convoluted after you've written a few GenServers (Phoenix channels / liveview).

midrus 5y ago
Liveview (as well as stimulus-reflex) promote minimal JavaScript by trying to push most interactions to the server, and let the server decide what should change in the frontend. So for example, to show a modal, you send an event that signals the user wants to show a modal, so the backend sends back the html for the modal. You click to close the modal, this sends an event to the backend, the backend sends you the diff or the instructions to remove the modal from the dom. In the hotwire world, the encouraged approach would be to already have the html in the dom, and use a stimulus controller to show or hide it [1]. And you only issue backend calls when you really need to reach to the backend anyway (like submitting a form, or refreshing some actual content). You don't call the backend just to signal a button was clicked so that the backend removes html if you can already do that in the frontend. Hotwire is not about avoiding JavaScript, hotwire is avoid organizing it well and reducing the amount you need. Of course you can do things wrong on both approaches, but it is what one approach promotes vs the other. As an example of why this is a problem, see this [2] example. I'm in Europe on a fiber connection, and clicking in one of the calendar days, and closing the modal feels just so terrible.... [1] https://tighten.co/blog/stimulus-101-building-a-modal/ https://tighten.co/blog/stimulus-101-building-a-modal/ [2] http://expo.stimulusreflex.com/demos/calendar/2021-05-01 http://expo.stimulusreflex.com/demos/calendar/2021-05-01
- granshaw 5y ago
  Yup. And as illustrated by OP's example links, avoid Stimulus Reflex (NOT stimulus.js) for production too. Apart from the stated reasons, the fact that websocket connections aren't scoped by User by default is a really, REALLY sharp edge!
  - hopsoft 5y ago
    As far as security is concerned, it's the application's responsibility to properly scope websocket connections... if and when that's appropriate. This is true of any websocket connection, not just those used by StimulusReflex or even ActionCable. As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly. Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.
    - HorizonShadow 5y ago
      This is also true of REST requests. They're not scoped to the user by default. In fact, Rails doesn't even have the concept of a user by default. The argument against using actioncable because it doesn't scope to users by default is roughly akin to arguing against rails in production because rails doesn't even know what a user is by default.
  - paramagicdev 5y ago
    Im a little puzzled by this. This is essentially like saying "Dont use Rails, the controllers arent scoped to the user by default" There are plenty of valid reasons to use websockets not scoped to a user. Also how is SR supposed to know your user scheme? What if you have a multi-tenant app and websockets should be scoped to an account and not a user? Im honestly confused by this statement.
nickjj 5y ago
> Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view? There's an open GitHub issue on LV which mentions when using live_redirect you're paying a very large penalty in page load speeds due to extra latency being introduced by LV: https://github.com/phoenixframework/phoenix_live_view/issues/1334 https://github.com/phoenixframework/phoenix_live_view/issues... Before this issue existed my non-scientific impression was the same. There was something that felt off when using sites that primarily used LV for navigation and loading content. It always felt like I was clicking, waiting a noticeable amount of time and then the content would appear -- even with a decent ping time (< 100ms). I never experienced that type of delay when using Turbolinks and now Hotwire Turbo with comparable ping times to a server.
- DiggyJohnson 5y ago
  Interesting analysis. Do you have any quick examples of site's that use LV? I'm curious.
  - nickjj 5y ago
    Not at the moment, but I remember someone posting an example LV page on Twitter a few months ago for pagination and I distinctly remember how delayed the page felt and I pinged 80ms to the server. Basically I've seen scattered examples when they were posted over the years on various social sites. I'm having a hard time finding a current example demo LV app that demonstrates page transitions using LV or to be honest any sites heavily using LV in general. But it should be reproduceable in a demo app that uses live_redirect to transition between pages. The issue has repeatable steps and it's been confirmed as a bug by the maintainers of LV, except it looks like it's going to be tricky to solve it.
ecmascript 5y ago
The trick is to use liveview for data that needs to come from the server anyway. I'd guess that the OP did use it for everything, like popups etc and did not do the same with hotwire.
- midrus 5y ago
  So what's the recommended approach for doing it without liveview in the liveview world? jquery? just document.addEventListener? That's what hotwire gives you: an opinionated approach and a golden path to do things in a manageable way.
  - eberfreitas 5y ago
    You can use alpine.js. There is even a way to integrate it with LV: https://dockyard.com/blog/2020/12/21/optimizing-user-experience-with-liveview https://dockyard.com/blog/2020/12/21/optimizing-user-experie...
    - midrus 5y ago
      <button @mouseenter.once=" fetch('/dropdown-partial.html') .then(response => response.text()) .then(html => { $refs.dropdown.innerHTML = html }) " @click="open = true" >Show Dropdown</button> Seriously? This has to be a joke.
      - alluro2 5y ago
        I was stumped when I saw it just now. What the heck...I guess the next thing, an amazing breakthrough, is going to be Alpine.scss style="background-color:$red-secondary;font-weight:bold"
        hnedeotes 5y ago
        I don't use alpine, but isn't that the blessed way of doing it in React/Vue/etc? I thought they were the ones introducing both @handlers on elements and JSX styling
joelbluminator 5y ago
Those advantages are really overblown and not worth the hit in missing libraries or missing hires.
- Scarbutt 5y ago
  Yep, the benefits most esoteric languages offer are superficial compared to the benefits a mainstream language ecosystem offers.
- midrus 5y ago
  Totally agree. I've been in this industry since 2001 and never, ever had a performance problem which couldn't be solved with just thinking what your code is actually doing. The bottleneck has been always the database, or the network, etc. The only problem I've had with threaded languages is running out of threads/processes due to making external API network requests, etc, but you learn to not block threads by using jobs, etc. And worst case, more hardware has been always cheaper than more developers due to less productive languages (hello Go! :wink: :wink:). You are not Google.
  - pantulis 5y ago
    I fully agree with you, but the demographics in HN is special -- you may be talking to people who work at Google-scale :P Anyway I believe you really need a very special case to make Elixir shine. Obviously you can build whatever you want with it, and it's really nice, but if you are doing consulting you are going on for a hard sell. And startups will sooner or later feel the crunch of more expensive and/or difficult hiring.
  - SZJX 5y ago
    Performance is one thing. I think another major benefit people cite for using Elixir/functional programming in general is the productivity aspect. Of course you may argue that this is easily outweighed by hiring pains as a company grows. Just wanted to mention that from a pure language/developer perspective, I'd much prefer to work with Elixir than something like Java or even Go.

midrus 5y ago

Liveview (as well as stimulus-reflex) promote minimal JavaScript by trying to push most interactions to the server, and let the server decide what should change in the frontend. So for example, to show a modal, you send an event that signals the user wants to show a modal, so the backend sends back the html for the modal. You click to close the modal, this sends an event to the backend, the backend sends you the diff or the instructions to remove the modal from the dom. In the hotwire world, the encouraged approach would be to already have the html in the dom, and use a stimulus controller to show or hide it [1]. And you only issue backend calls when you really need to reach to the backend anyway (like submitting a form, or refreshing some actual content). You don't call the backend just to signal a button was clicked so that the backend removes html if you can already do that in the frontend. Hotwire is not about avoiding JavaScript, hotwire is avoid organizing it well and reducing the amount you need. Of course you can do things wrong on both approaches, but it is what one approach promotes vs the other. As an example of why this is a problem, see this [2] example. I'm in Europe on a fiber connection, and clicking in one of the calendar days, and closing the modal feels just so terrible.... [1] https://tighten.co/blog/stimulus-101-building-a-modal/ https://tighten.co/blog/stimulus-101-building-a-modal/ [2] http://expo.stimulusreflex.com/demos/calendar/2021-05-01 http://expo.stimulusreflex.com/demos/calendar/2021-05-01

granshaw 5y ago
Yup. And as illustrated by OP's example links, avoid Stimulus Reflex (NOT stimulus.js) for production too. Apart from the stated reasons, the fact that websocket connections aren't scoped by User by default is a really, REALLY sharp edge!
- hopsoft 5y ago
  As far as security is concerned, it's the application's responsibility to properly scope websocket connections... if and when that's appropriate. This is true of any websocket connection, not just those used by StimulusReflex or even ActionCable. As noted by the parent, latency is certainly a consideration when using such tools, but there are a myriad of libs and techniques that can be leveraged to help you build great user experiences with StimulusReflex and LiveView. You just need to consider your options and architect accordingly. Note also that the expo demos for StimulusReflex are incredibly old (a few major versions behind at this point) and were created in haste to help people grok concepts via example. They were never intended to be a canonical guide of how to best architect such apps at scale. We're considering taking the expo site offline in favor of more specific and better architected demos.
  - HorizonShadow 5y ago
    This is also true of REST requests. They're not scoped to the user by default. In fact, Rails doesn't even have the concept of a user by default. The argument against using actioncable because it doesn't scope to users by default is roughly akin to arguing against rails in production because rails doesn't even know what a user is by default.
- paramagicdev 5y ago
  Im a little puzzled by this. This is essentially like saying "Dont use Rails, the controllers arent scoped to the user by default" There are plenty of valid reasons to use websockets not scoped to a user. Also how is SR supposed to know your user scheme? What if you have a multi-tenant app and websockets should be scoped to an account and not a user? Im honestly confused by this statement.

nickjj 5y ago

> Maybe I'm missing something, but doesn't this have precisely the same latency characteristics as live view? There's an open GitHub issue on LV which mentions when using live_redirect you're paying a very large penalty in page load speeds due to extra latency being introduced by LV: https://github.com/phoenixframework/phoenix_live_view/issues/1334 https://github.com/phoenixframework/phoenix_live_view/issues... Before this issue existed my non-scientific impression was the same. There was something that felt off when using sites that primarily used LV for navigation and loading content. It always felt like I was clicking, waiting a noticeable amount of time and then the content would appear -- even with a decent ping time (< 100ms). I never experienced that type of delay when using Turbolinks and now Hotwire Turbo with comparable ping times to a server.

DiggyJohnson 5y ago
Interesting analysis. Do you have any quick examples of site's that use LV? I'm curious.
- nickjj 5y ago
  Not at the moment, but I remember someone posting an example LV page on Twitter a few months ago for pagination and I distinctly remember how delayed the page felt and I pinged 80ms to the server. Basically I've seen scattered examples when they were posted over the years on various social sites. I'm having a hard time finding a current example demo LV app that demonstrates page transitions using LV or to be honest any sites heavily using LV in general. But it should be reproduceable in a demo app that uses live_redirect to transition between pages. The issue has repeatable steps and it's been confirmed as a bug by the maintainers of LV, except it looks like it's going to be tricky to solve it.

ecmascript 5y ago

The trick is to use liveview for data that needs to come from the server anyway. I'd guess that the OP did use it for everything, like popups etc and did not do the same with hotwire.

midrus 5y ago
So what's the recommended approach for doing it without liveview in the liveview world? jquery? just document.addEventListener? That's what hotwire gives you: an opinionated approach and a golden path to do things in a manageable way.
- eberfreitas 5y ago
  You can use alpine.js. There is even a way to integrate it with LV: https://dockyard.com/blog/2020/12/21/optimizing-user-experience-with-liveview https://dockyard.com/blog/2020/12/21/optimizing-user-experie...
  - midrus 5y ago
    <button @mouseenter.once=" fetch('/dropdown-partial.html') .then(response => response.text()) .then(html => { $refs.dropdown.innerHTML = html }) " @click="open = true" >Show Dropdown</button> Seriously? This has to be a joke.
    - alluro2 5y ago
      I was stumped when I saw it just now. What the heck...I guess the next thing, an amazing breakthrough, is going to be Alpine.scss style="background-color:$red-secondary;font-weight:bold"
      - hnedeotes 5y ago
        I don't use alpine, but isn't that the blessed way of doing it in React/Vue/etc? I thought they were the ones introducing both @handlers on elements and JSX styling

joelbluminator 5y ago

Those advantages are really overblown and not worth the hit in missing libraries or missing hires.

Scarbutt 5y ago
Yep, the benefits most esoteric languages offer are superficial compared to the benefits a mainstream language ecosystem offers.
midrus 5y ago
Totally agree. I've been in this industry since 2001 and never, ever had a performance problem which couldn't be solved with just thinking what your code is actually doing. The bottleneck has been always the database, or the network, etc. The only problem I've had with threaded languages is running out of threads/processes due to making external API network requests, etc, but you learn to not block threads by using jobs, etc. And worst case, more hardware has been always cheaper than more developers due to less productive languages (hello Go! :wink: :wink:). You are not Google.
- pantulis 5y ago
  I fully agree with you, but the demographics in HN is special -- you may be talking to people who work at Google-scale :P Anyway I believe you really need a very special case to make Elixir shine. Obviously you can build whatever you want with it, and it's really nice, but if you are doing consulting you are going on for a hard sell. And startups will sooner or later feel the crunch of more expensive and/or difficult hiring.
- SZJX 5y ago
  Performance is one thing. I think another major benefit people cite for using Elixir/functional programming in general is the productivity aspect. Of course you may argue that this is easily outweighed by hiring pains as a company grows. Just wanted to mention that from a pure language/developer perspective, I'd much prefer to work with Elixir than something like Java or even Go.