All the new terms associated with Hotwire, such as Turbo, Drive, Frames, Stimulus, Strada, etc. can be confusing to understand at first. This post provides a brief introduction to Hotwire and its component frameworks.
We'll start with a brief overview of the existing approaches to building web applications and the problems associated with them. Then I'll introduce Hotwire, and wrap up with a short description of the different sub-frameworks that make Hotwire.
We’ll also learn how these frameworks fit together to provide a cohesive solution for the front-end ecosystem, not only for Ruby on Rails, but for any back-end framework, such as Laravel.
Here're the topics we'll cover in this article.
- Traditional Web Architecture
- Single-Page Applications (SPAs)
- Disadvantages of SPAs
- A Brief Introduction to Hotwire
Let's get started.
Traditional Web Architecture
To understand Hotwire, we first need to know how a typical request-response cycle works when a browser requests a web page.
When you go to a website in the browser or click a link on a page, it makes a GET request to the server, which sends an HTML response to the requesting browser. The browser then parses the HTML and displays the web page.
Now, these assets are cached on the browser most of the time, which makes this process relatively fast, but the basic idea remains the same. The browser has to parse and interpret the whole HTML again. So the web application doesn’t get a native application-like feeling. It still feels like a website.
This was the original web architecture (that made the web popular and successful), and many web applications still work that way. However, with advances in browsers, a new category of web applications became popular in the last ten years, known as Single-Page Applications, or SPAs for short.
Single Page Applications get a lot of their speed and responsiveness from not constantly reloading the browser, tearing down the application process, only to reinitialize it on the very next page.
A good example of a single-page application is the Rails forum powered by Discourse. When you click on a message on the forum, the browser doesn’t reload the whole page, unlike a link on the MDN documentation, which uses the traditional web architecture. Notice how the full page reloads whenever you click any links on MDN, but not on the Rails forum.
Disadvantages of SPAs
Also, you might have to duplicate the view templates both on the frontend and backend. Managing and sharing links also becomes tricky, as you are always on the same page.
SPAs are also not very SEO - friendly. As Barry Adams explains,
What happens when you use React without server-side rendering is that the crawler halts on the very first page because it can’t see any hyperlinks to follow. It sends the page to the indexer, which then has to render the page and extracts the hyperlinks, which will then be added to the crawler’s queue.
It makes the crawl process incredibly slow and inefficient.
In my experience, most of these "modern" SPA apps (and I mean most business applications, not the slick demos you see on the React or Next.js websites) are fragile, poorly implemented, have bad first-load times, don’t work well with the browser’s back and forward buttons, and cause a bad user experience.
As Stefan Tilkov explains in his 2016 post Why I hate your Single Page App,
Maybe your single page app is different, but the ones that I know break most of my browser’s features, such as the back and forward buttons, page refresh, bookmarking, sending a link, or opening a link in a new window or tab.
They offer no way to link to something that I look at. (Oh, I know there are exceptions to this rule, but they typically require effort — a lot more than many developers are prepared to invest).
They are bloated and slow to load, even though the actual information they display and the interaction they offer is very simple.
To be fair, Single Page Applications do try to address these concerns using various techniques, but that’s a big topic in itself. Some SPAs are even a pleasure to use, especially if implemented well. The best example of a flawlessly executed single-page application is Ghost, the blogging platform I use to write and publish this blog.
A Brief Introduction to Hotwire
Hotwire stands for HTML over the wire. It is a collection of techniques that tries to get the best of both worlds, keeping the original, simple web architecture of sending HTML over the wire, while not losing the performance benefits of Single Page Applications.
Hotwire is not a single framework; it’s a suite of different frameworks that allow you to send HTML responses over the wire.
- Strada (not yet released) works with native applications, making it easy to progressively level-up web interactions with native replacements. Hopefully, 37Signals will release Strada in 2023.
Turbo is the most important framework in Hotwire. It uses multiple techniques to provide a SPA-like experience, while still keeping the simplicity of traditional web applications, i.e. sending HTML over the wire.
- Turbo Drive accelerates links and form submissions. It listens for link clicks or form submissions, performs them in the background, and updates the page without a full reload. Learn how Turbo Drive works.
- Turbo Frames divides pages into independent contexts called frames (not iframes). Turbo captures link clicks and form submissions inside a frame, automatically updating the frame contents after receiving a response. Learn how Turbo Frames work.
- Turbo Streams delivers page changes over WebSocket, SSE, or in response to form submissions using just HTML and a set of CRUD-like actions.
If all these different frameworks and techniques are already sounding confusing, don’t worry. You won’t be using all of them equally, all the time. Here’s a diagram that might help you understand how it all fits together.
Inside Turbo, Turbo Drive will satisfy most of your needs for fast performance. When you need additional responsiveness, you use Turbo Frames, and finally, in a few cases where you need to bring your application alive, such as sending live updates from the server, you will use Turbo Streams.
This is just a very high-level overview of these components. If you are interested in learning more, I have a detailed tutorial on building a to-do list with Hotwire that shows how to build a single-page web application using Hotwire.
I hope this brief introduction helped you get a big-picture overview of Hotwire and understand how different parts of it fit together to provide a cohesive solution for the front-end ecosystem.
The architecture of Hotwired applications is much easier to understand and reason about, as they're just traditional web applications. They also feel as snappy as a SPA, as we aren't reloading the whole page on each request. Maintaining them is much simpler, and you don't have to use separate frontend and backend teams.
I hope you found this article useful and that you learned something new.
If you have any questions or feedback, didn't understand something, or found a mistake, please leave a comment below or send me an email. I look forward to hearing from you.
Please subscribe to my blog if you'd like to receive future articles directly in your email. If you're already a subscriber, thank you.