I was taking a peak of the source over on hey and noticed how they are leveraging the next version of Turbolinks. I am super curious about the new Turbolinks Frame. I stumbled across this repo which gives us a preview (somewhat). How will Stimulus integrate in the next release?
Side note: First time post here, but I’ve been using Stimulus and Turbolinks for quite some time now. I generally combine these 2 libraries with mithril.js and sometimes rely upon the the http://meiosis.js.org/ state management pattern for when I need more complex structures stored in state, it’s a rather odd combination but it works wonders for my use cases and helps provide a form of dom hydration when rendering virtual nodes – I just want to communicate how deeply appreciative I am to all maintainers and contributors of stimulus and turbolinks. This community is really top. Also, @adrienpoly your activity here in discourse has been a great help over the years, so thank you.
I suspect a fair few changes will be shipping. While I personally don’t have the answers looking over Hey’s source I was able to dig up some interesting features. It is however rather irritable the secrecy that Basecamp retains with this shit because it’s impossible to plan ahead especially how utterly stagnant Turbolinks has become in terms of PR’s not being addressed.
@adrienpoly I use Elixir and haven’t dabbled with Rails in a very long time, what were your findings in that repo?
@leastbad Despite what the critics say in your linked thread, I found your wording and question to be quite valid, same as your response. Shame you caught some heat on it.
@adrienpoly@leastbad
So, I’ve been thinking about this new magic for a while. And I actually built something like that because I think react and other stuff is just overkill in most scenarios
My implementation is simple. Using rails’s request.variant and Controller concerns, you can make life super easy. Here’s the gist implementation of my “turbolinks-frame” system.
Hey @tdak, I’m really impressed that you took the way an elephant feels blindfolded and made a pretty solid elephant-shaped tool.
While we are all endlessly curious about what the final TL6+webcomponents+Rails helper combo will look like, the reality is that many of us simply got tired of waiting a long time ago and have since poured thousands of hours into building StimulusReflex and CableReady. There are even tools that build on these building blocks suchs as Futurism for lazy-loading and Optimism for remote form validation (both based on CableReady, which is the most under-rated tool in the Rails ecosystem).
At this point, the functionality of TL6 as showcased in Hey is a small subset of what is already available in CableReady. While there is nothing stopping people from using the TL6 mechanisms - they will be baked-in, framework approved, after all - alongside CableReady and StimulusReflex, it’s distinctly possible that most developers would still prefer the power and flexibility of StimulusReflex, and not just because of a wild head-start.
Of course, it doesn’t hurt that you can use StimulusReflex today.
I’ve tried StimulusRelfex probably over a year ago, because I was really not impressed with SPAs and react and all the other extra unnecessary stuff. I was really looking for something simple that would map a section of my html page to a controller. I really haven’t needed/thought about action cable or any cableready because my users are rarely in real time update situations. In most cases, they don’t keep dozens of tabs open and they close the browser after they are done using the app.
When I saw turoblinks-frame setup in Hey, I realized it was something similar to what I had already built, so I just modified my solution a little to match it. In case TB6 comes out and works in a similar way, I won’t have to change much of my code. I really hope that it does.
I think StimulusReflex is awesome, by the way. Because it is so easy. It would be on the next level if it can be matched to controller actions, instead of separate reflexes, using variants or something like that. And maybe you are already working on it.
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.
Wow, you’re really trying to sell me on this. I appreciate the effort. And I had a chance to go through the StimulusReflex docs today. Looks impressive.
I love the fact that it’s not just me who is annoyed at the current state of let’s make the app do stuff and then make the browser do exact same thing in javascript.
Love the end result of the diagram. Profit.
Definitely going to try using it, spin up a new rails app to try it out.
Thanks for taking your time. Really appreciate it.
It wasn’t clear if you were saying you stopped using Turbolinks completely and moved on to StimulusReflex, or if you still used both. Your recent comment was clear.
We’ve been told to expect that Turbolinks 6 makes UJS obsolete, that it fixes remote form validations, and that Rails will gain new helpers that emit web components called “Turbolinks frames” which are used to achieve something similar to the way Laravel’s LiveWire updates work (via Ajax). (Apologies if my paraphrasing is weak, this is just what I currently remember.)
Unfortunately, none of this has been revealed except as a series of unofficial deep dive posts into the workings of the Hey email service.
It’s these aspects of a future Turbolinks that many folks have grown tired of waiting for.
Personally, the only reason I still leverage Turbolinks is because it works well with SaaS services that SSR render content and leverage consumer facing templating engines. It also works wonderfully with static sites but with that said the current version of Turbolinks is riddled in bugs and the project has become stagnant.
I’ve seen SR around but I don’t work with Rails and not sure how useful it would be for Elixir and/or Serverless based environments that leverage cloud DB’s like Fauna. In most cases I find myself doing almost everything with the virtual DOM and have began to treat my Stimulus/Turbolinks applications as legacy. It’s rather sad tbh, I really loved working with them.
