Interesting note, on Twitter DHH mentioned that they have some additional "magic" that they're using to do frontend work. It sounds like HTML over websockets, not unlike Phoenix LiveView or (tooting my own horn here) our recently released Motion library (https://github.com/unabridged/motion) which both allow you to use the server as your single source of truth while providing reactive UI components on the frontend. He indicated they'll be releasing more later this year.
Nice, this is much closer to LiveView than Stimulus Reflex. Will check it out when I have time.
Slightly off topic:
>Github's ViewComponent is currently the de-facto standard for component/presenter-style libraries for use with Rails and likely will make it into Rails eventually.
I can't speak for DHH, and I don't see anywhere that he commented in the PR. My read of the thread is that there are open questions about the best way to structure this abstraction, so the minimal interface to allow for clean community experimentation has been stabilized in the meantime.
It is probably like LiveView but i think its over http. Like Laravel Livewire https://laravel-livewire.com/
I am not sure websockets and ruby are best of friends.
ActionCable doesn't really scale that well, but can work for small loads. In addition, there's AnyCable to bring high scalability using the ActionCable protocol for easy Rails interop. With Motion, we are planning support for AnyCable.
Kind of, yeah. ActionCable is just the plumbing though. The functionality of Motion, this forthcoming magic, LiveView, etc is all a step higher up. Motion uses ActionCable as the implementation mechanism, the "pipe" that data transfers over. But ActionCable itself is basically just "you can use websockets with Rails!" and not much else.
Well sure, and inevitably there are going to be gem(s) or framework additions that make it easier to send HTML down the pipe, which is how I read your comment. We don't disagree!
