Nice deep dive. On a tangential point: nowadays Turbo Streams are less needed in Rails, because of the way Turbo automatically kicks in by default. And in most (not all) situations, backend doesn't really save much time returning a piece of a page vs a full page, since in most backends preparing data for response takes 10s of milliseconds. So might as well just stick with default, unless you know that you specifically need to serve some granular change. While learning this stuff, I wrote a little FAQ (where I was the frequent asker of questions) that clarifies some things: https://notes.max.engineer/turbo-8-faq
I wouldn't generalize it that much. There are few patterns where Turbo Streams, subscriptions, and permanent frames still make a lot of sense.
One classic case is user notifications - like the user icon in the corner. That's perfect as a permanent lazy frame, with a subscription watching for any user-related updates. This way you don't have to think about updating that widget across different pages, and you can centralize all user-related async events in
one controller.
Another pattern is real-time dashboards. You never know which part of the dashboard will change, and it's actually simpler on the backend: you just track what was updated and push that specific part. Clean and efficient.
I recently finished shooting a video course for Phlex and I found that naming the Turbo Stream section at https://beautifulruby.com/phlex#unit-5 was the most challenging because of Turbo Streams and Turbo Broadcasts.
My recommendation: Turbo Drive & Pagemorphs are what most people should use for most problems. Drive reduces flickering between page loads and Pagemorphs list to channels on the server to reload the page if something changed.
I think Turbo would benefit from positioning itself more closely to Rails and simplifying the terminology. If you look at the https://hotwired.dev website, you won’t find Rails and you’ll find a bunch of words like Stimulus, Drive, Streams, Broadcast, etc. The docs aren’t entirely coherent either.
What do you mean by “Pagemorphs”? A quick Google search suggests you’re the only person using this term so it’s hard to know what you’re recommending. I think it must mean e.g. https://turbo.hotwired.dev/handbook/page_refreshes?
Nice deep dive. On a tangential point: nowadays Turbo Streams are less needed in Rails, because of the way Turbo automatically kicks in by default. And in most (not all) situations, backend doesn't really save much time returning a piece of a page vs a full page, since in most backends preparing data for response takes 10s of milliseconds. So might as well just stick with default, unless you know that you specifically need to serve some granular change. While learning this stuff, I wrote a little FAQ (where I was the frequent asker of questions) that clarifies some things: https://notes.max.engineer/turbo-8-faq
I wouldn't generalize it that much. There are few patterns where Turbo Streams, subscriptions, and permanent frames still make a lot of sense.
One classic case is user notifications - like the user icon in the corner. That's perfect as a permanent lazy frame, with a subscription watching for any user-related updates. This way you don't have to think about updating that widget across different pages, and you can centralize all user-related async events in
one controller.
Another pattern is real-time dashboards. You never know which part of the dashboard will change, and it's actually simpler on the backend: you just track what was updated and push that specific part. Clean and efficient.
I recently finished shooting a video course for Phlex and I found that naming the Turbo Stream section at https://beautifulruby.com/phlex#unit-5 was the most challenging because of Turbo Streams and Turbo Broadcasts.
My recommendation: Turbo Drive & Pagemorphs are what most people should use for most problems. Drive reduces flickering between page loads and Pagemorphs list to channels on the server to reload the page if something changed.
I think Turbo would benefit from positioning itself more closely to Rails and simplifying the terminology. If you look at the https://hotwired.dev website, you won’t find Rails and you’ll find a bunch of words like Stimulus, Drive, Streams, Broadcast, etc. The docs aren’t entirely coherent either.
What do you mean by “Pagemorphs”? A quick Google search suggests you’re the only person using this term so it’s hard to know what you’re recommending. I think it must mean e.g. https://turbo.hotwired.dev/handbook/page_refreshes?
Been using Turbo (and Turbolinks before it) for 10+ years, mostly outside Rails. It's awesome in that context.
Can't really see how making it more Rails-centric would help - more likely it'd just cause a fork for everyone using Hotwire without Rails/Ruby.
Any plans for purchase parity for South East Asia?
Shoot me an email, brad@beautifulruby.com
Exactly that.