So this receives the full HTML page and does a near-zero-damage “morphing” as opposed to Hotwire which either does full page dumb replacement or asks you to define which sections to replace? Does that sound right?
> as opposed to Hotwire which either does full page dumb replacement or asks you to define which sections to replace
It's not that dumb in practice because for a lot of things Hotwire uses HTTP instead of WebSockets which means you can take advantage of what HTTP has to offer such as caching.
That means if you decide to dynamically load a menu's contents with a Hotwire Turbo Frame then it's only sent over the wire once and assuming its content doesn't change, it'll serve a 304 content not modified for future requests.
For pushing updates with Turbo Stream which is done over WebSockets, I'm pretty sure it'll push that snippet of HTML (let's say a user's comment) over WebSockets and then either append or prepend it to the DOM based on however you configured it to be inserted. And if you edited that comment later on, it will replace that snippet of HTML that was previously sent (since it's the same ERB template). It won't re-render the full page.
There are a lot of wonderful upsides to this approach, yes.
It’s just... people think those technologies are congruent but the overlaps are actually minimal.
For any rather sophisticated UI you can (and will want) to use both.
For example: repaint a data visualization. With Hotwire you can only replace it and start fresh, with SR you can just surgically morph data attributes without disconnecting your stimulus controllers
Basically all you to is to call a remote procedure, which you can do by adding a simple `data-reflex="click->Todo#toggle`. In the remote method you change something about the state (for example db, redis). The server rerenders the page and morphs the difference.
If you need more control you can get it by defining which elements to render and to morph.
also, StimulusReflex predates Hotwire for 1 year and is already pretty hardened :-)