[midrus]

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

[granshaw]

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!

[paramagicdev]

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.

[ipaddr]

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.

[hopsoft]

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]

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.

[danjac]

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

[paramagicdev]

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.