Having used (and frequently disabled!) Turbolinks in Ruby on Rails applications, I have to pitch in and say that I dislike it in general. Because it loads page content in an impredictable way, and normal browser events are not triggered like you (or many of the front-end libraries you might use) expect to, you can and at some point will encounter odd bugs that only occur when going from Page A -> Page D -> Page B -> back to Page A for instance. Those things are very difficult to debug, which meant that in all apps that did not really need it, Turbolinks got turned off.
1 Like
I’m not sure how this is related to Turbolinks specifically. Any pjax like library has to deal with the fact that the browser won’t trigger another onload event or some event listeners need to be removed & reattached or attached to a global parent. That’s why those libraries provide their own events for when pages are changed. Even libraries like react need to deal with that, but thoroughly handle that part for you with their knowledge about the rendered content.
2 Likes
If you want to see a more up-to-date 2016 presentation about how Basecamp does the hybrid native approach you are bringing up (including actual code) here is an IMO excellent opinionated talk: https://www.youtube.com/watch?v=SWEts0rlezA
3 Likes
Currently watching the talk, but I think it answers the question that I posed here a few minutes before you posted the video.
It seems that the Stimulus and Turbolinks approach is a very pragmatic approach.
1 Like
This talk made me finally go with Turbolinks & Stimulus combo. I have previously considered and tried Unpoly as well. The Android/iOS adapters that Turbolinks comes with are a bonus.
