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.
As for NEW MAGIC, DHH mentioned it will have a Rails server side aspect to it so I don't think we can compare these tools directly.
He did say other server side frameworks could implement similar behavior too but it would involve the framework having built-in support for websockets and job queues. This is based on a question I just asked him on Twitter at https://twitter.com/dhh/status/1334953167327547397.
So it sounds like NEW MAGIC will probably make it super easy to push / broadcast stuff from the server to the client, but to get everything working with a really nice API and it being seamless will require a substantial amount of work if you planned to re-invent it in another framework.
The new turbolinks they use on hey.com is using a concept named „portals“ so different parts of the web application can be refreshed independently. My linked inside hey.com articles are very interesting.
Yeah that's the interesting part. It sounds like maybe there will be some overlaps in Turbolinks 6 and NEW MAGIC when it comes to partial updates.
Maybe for basic partial page updates where you don't need to broadcast something to every connected client over websockets then Turbolinks 6 will be enough on it own. If that ends up being the case that's amazing because it'll be fully client side.
In any case the near future is looking to be the best its ever been for developing very nice feeling apps without going the SPA route with any back-end technology.
This is exactly what CableReady was built for... to update the DOM from any Ruby process (in the request cycle or not). It was designed from the beginning to update the DOM from out-of-band non-request based workflows like background jobs.
Interesting point about grassroots vs top down. I think that definitely plays into the equation. Another big part of it is that developers seem to a unique class of workers that don’t seem learn much from those who preceded them. We love to reinvent things, in part due to the snowflake effect & NIH syndrome. The other reason I think the wheel keeps being reinvented in tech is due to the developer workforce essentially doubling every 5 years... also, the sad reality that ageism coupled with very few long term viable career tracks available for software writers pushes a lot of experience and wisdom out of the industry.
I'm not sure any other technology stack would have fared much better.
Consider that 6 years, 2 months, and 20 days passed between Rails 3.2 and Rails 5.2. That's quite a bit of time for the framework to evolve. Then factor in the customizations from several non-framework dependencies and those added by GitHub.
This is an incredible achievement no matter how you slice it.
