I've transitioned from rails-everything to working exclusively with front-end frameworks and libraries (react, angular, polymer), and I'll tell you this still: if I'm working in rails, I use turbolinks. It's a wonderful approach, way under-appreciated.

When two or more things on the page need to know about each other/you require a high-fidelity interaction that you can't easily handle with just it, then yeah - reach for vue, react, or what have you. But no need to start there! Use those as targeted air strikes

I think the issue is that with out of the box rails apps, there's not a lot of opportunity to perform one of these 'targeted air strikes'. Emergent requirements incentivize quick solutions and you can end up with a bunch of ad-hoc foundation components and really bad jquery-ui slapped around in erb files.

At least, that's been my (very limited) experience with it.

I've found it easier to just drop in `react-rails` and build out react components for certain situations than to try and string a bunch of jquery together.

I love turbolinks as well. I can get < 100ms to screen with it without almost any extra effort.

Have to disagree on this one for anything but the most basic apps (think blogs and lots of static content). I'd have rewritten my entire app over by now with the "targeted air strikes" approach.

When turbolinks first hit most people went "oh it breaks jquery" and never touched it again.

Which is a shame considering how much it speeds most typical applications up by completely ignoring the mobile advantages.

Turbolinks just "works" so easily out of the box - for most use cases of persisting header / footer / etc between pages your users will think it's a "true" SPA. Even comes with the customizable css loading indicator now to re-enforce that feeling of speed.