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.
There are plenty of valid reasons to not scope it to a user. Having the default scoped to the most common case makes sense.
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.
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.
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.
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.
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