I lot has changed in the past year. Night and day. Let me try to sell you for a moment.
StimulusReflex isn’t about building “real time” updates any more than Turbolinks is. It just happens to use ActionCable as a transport mechanism - and soon we’ll have support for a message_bus (aka Ajax) transport as well.
StimulusReflex is about moving UI state management back to the server. If you think about what’s gone seriously wrong in web development - where things have become unacceptably complex - it’s that we now use JS to build UI patterns that require developers to securely synchronize state between the front-end and back-end. This is a can of worms in a multi-user environment served over a stateless protocol. My bar-room napkin math suggests that 80% of the worst part of being a developer today comes down to issues stemming from client-side state.
SR/CR represents an opportunity to move away from that. It’s strongly inspired by Sam Stephenson’s Turbolinks talk at RailsConf where he reminds us that things don’t need to be complicated. Yes, it requires a shift in how you think about building your app… but it’s more of an unlearning of a decade’s worth of bad habits. When you suddenly realize that you’re now able to write way less code that is itself way less complicated and you don’t have to spend any time synchonizing state… it’s tremendously liberating. We’re seeing 1-2 person teams rapidly implementing complex UIs that previously weren’t possible on the schedule their product sprint cycles allowed, even though this style of development is technically new to all of us.
The default mechanism of SR has always been a full-page morph that does 1:1 match with the controller action. We only recently added two new code pathways that don’t touch the controller action. I made a chart to show how this all fits together here.
I sincerely hope that you’ll take another look at both CableReady and StimulusReflex. You could be using CableReady independently of StimulusReflex and still coming out way ahead.