Hacker News Reader

Comment by benwilson-512 | Hacker News Reader

> 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).

View on HN

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/ [2] http://expo.stimulusreflex.com/demos/calendar/2021-05-01

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!

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.

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.

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.

Wouldn't you just override the defaults if you need to scope at the account level?

There are plenty of valid reasons to not scope it to a user. Having the default scoped to the most common case makes sense.

> 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

You could also use a turbo-frame here: the modal might contain data that could be expensive to pre-render in the first pass. For example, you have a list of things and you want a modal to show additional details for each thing rather than require navigation to a detail view. Those additional details might need more SQL queries that you don't necessarily want to include in your initial list render, so it makes sense to have that pulled from a separate request.

Closing the modal though should not require another round-trip to the server, that can be done with Javascript.

Nothing about StimulusReflex pushes you away from this approach. This all comes down to the developer.

StimulusReflex is built on top of Stimulus. The point of SR isnt necessarily to write less javascript, its an easier way to sync client and server state and have a single source of truth.

Use SR where SR makes sense, but just because you have a hammer doesnt mean everything is a nail.

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.

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.

You can use alpine.js. There is even a way to integrate it with LV: https://dockyard.com/blog/2020/12/21/optimizing-user-experie...

<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.

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"

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

Maybe, except in React you have a huge community, formatters, linters, editors, testing tools/libraries and an overall architecture for doing things. Alpine seems worse than just using jQuery. I'd prefer to use something like Unpoly before using this monstrosity.

Then don't use it, no one is forcing you man. Just because it is not for you doesn't mean its bad or that other people can't have use for it.

You don't really need to use alpine either if you use Phoenix with Liveview, you can probably get away with just using vanilla js if all you really need is some small functionality of modals popping up etc.

why would you load the dropdown HTML separately, just render it along in the template with x-show="open" and have the @click="open=true"?

This is an example from their docs. That's why.

There's the so-called "PETAL" stack these days: Phoenix, Elixir, Tailwind.css, Alpine.js, LiveView. In that scenario, you use Alpine.js for the frontend-only stuff.

> 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...

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.

Interesting analysis. Do you have any quick examples of site's that use LV? I'm curious.

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.

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

Yep, the benefits most esoteric languages offer are superficial compared to the benefits a mainstream language ecosystem offers.

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.

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.

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.

Reply on news.ycombinator.com