Turbolinks, my favorite way to build hybrid apps, recently received a huge update.
What’s Turbo(links)?
Turbolinks is a tiny JavaScript library bundled into Rails apps that makes pages load way faster. When a link is clicked, the library takes over and performs the request via AJAX then replaces the <body> element with the response.
Developers can leverage these “hooks” to build hybrid applications based on the mobile web site they already have. There are native iOS and Android components that work with the JavaScript to create native-feeling interactions.
The native app renders the mobile web view and the frameworks handle the “glue” in between. Think: clicking a link pushes a new controller on the navigation stack. These tools enable small teams of developers to build high-fidelity cross-platform apps. Basecamp, Hey, Zaarly, BeerMenus, and more are all Turbolinks-powered hybrid apps.
Turbo and Hotwire
Cosmetically, the framework is now called Turbo and lives under the Hotwire “namespace” both on GitHub and online.
The web side of Turbo saw a slew of new features and existing things to play with. To show how powerful Turbo is, watch DHH create a live-updating chat application in just 15 minutes. 🤯
The iOS component, called an adapter, received a much smaller update. The upgrade path from Turbolinks is small and relatively painless; I was able to migrate two existing apps in a few hours each.
The most exciting new feature for the native frameworks is Path Configuration. This moves the URL routing logic to a JSON file. The best part is that this file can live on your server, enabling remote configuration of different URLs. 💪
I’m compiling 5 years of Turbo(links) experience 📓
Since I started working with Turbo(links) in 2015, I’ve been noting all the gotchas and rough patches. I’m slowly compiling these into something more formal to share with the public.
That said, I’m not sure if a book, video course, or blog post series will be the best fit. If you’re interested in learning more about Turbolinks, how would you prefer to learn?
P.S. If you need help on your Turbo(links) project ASAP don’t hesitate to send me an email!
How do you feel about hybrid? 🤔
Personally, I find them an amazing middle ground for small teams to manage the three big platforms at the same time.
How do you feel about hybrid? I’d love to hear what you think in the comments!
More about me
I'm Joe and I write every week on Masilotti.com. I also tweet about this kind of stuff on Twitter. This snippet was part of my newsletter, The Masilotti Monthly.
Top comments (8)
Is it possible to change the target to other elements than
<body>? For example I have website with top bar and left sidebar. When links are clicked, I want it to get loaded in the content area while the top and sidebar remains unchanged.It sounds like you could benefit from Turbo Frames.
For example, set up your main content as a Turbo Frame and have link clicks only reload the content inside that area. Leaving your top bar and left sidebar untouched.
So what I understand is that I only need to return response which contains
<turbo-frame id ...>element. If the response have that frame, then turbo will replace that element instead of<body>?That's good news, I've used Turbolinks before, good to see that it's not falling by the wayside but that it's being actively developed, with an ambitious new release and roadmap!
And good to see that it also works with other frameworks, e.g:
pypi.org/project/turbo-django/
github.com/tonysm/turbo-laravel
The only thing I would have wished (very minor criticism) is that they would have chosen a more original name - "Turbo" is hard to Google (you really need to search for "turbo hotwire" to get meaningful search results) ... TBH 'Turbolinks' was a better name in that regard.
100% agree with you there. I've been touting myself as a "Turbolinks developer" for a few years now. Googling "Turbo developers" will be much harder and just sounds plain weird!
I guess they wanted to go all fancy and hipster with that short "Turbo" moniker, but maybe they didn't realize about the drawbacks ... gotta be "turbo hotwire" then maybe, to make it recognizable and "Googleable"?
But that also doesn't sound great ... let's just keep calling it Turbolinks! :-)
I'm eager to replace my custom XHR/HTML update code (based on JS snippets with jQuery) with Hotwire. It always felt kind of "alien" in my RoR project, so I'm glad I can throw it away now.
However in general I think Hotwire is out-of-time. It's not because I'm a big fan of the Javascript ecosystem, but it's because I'm a big fan of the decentralised web, you know, blockchain, DLT, Web 3.0, DeFi... does it ring a bell? And that technology relies on JS/WASM apps in the browser.
That's a fair point, but how much of the web is actually using any of that? List 10 businesses that are and I can name 20 that aren't. And back and forth. It feels weird to dismiss an entire workflow because a portion of the web doesn't immediately have need for it.
On top of that, there's nothing stopping you from layering these features on top of your Hotwire implementation.