This post introduces Hotwire, the suite of front-end frameworks shipped with Rails 7. It starts with a brief overview of the existing approaches to building web applications, introduces Hotwire, and wraps up with a short description of the different sub-frameworks that make Hotwire. We’ll also see how these frameworks fit together to provide a cohesive solution for the front-end ecosystem.
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 text 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.
Single Page Applications
An example is the Rails forum powered by Discourse, a Single Page Application. When you click on a message on the forum, the browser doesn’t reload the whole page, unlike a link on the MDN documentation page.
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.
Disadvantages of SPA
Also, you might have to duplicate the view templates both on the front-end and back-end. 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 in his post,
It makes the crawl process incredibly slow and inefficient.
In my experience, most of these “modern” apps are fragile, poorly implemented, have terrible first-load times, don’t work well with the browser’s back and forward buttons, and cause a bad user experience.
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. A good example is Discourse.
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.
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.
Now I’ve been playing with Hotwire for the past few days, and working on a Hotwire application is just fun. There’s no complexity associated with setting up the framework like React or having to configure Webpack, which I never enjoyed.
Hotwire is not a single framework; it’s a suite of different frameworks.
- Strada (not yet released) works with native applications, making it easy to progressively level-up web interactions with native replacements.
Turbo uses the following techniques to provide a SPA-like experience, while still keeping the simplicity of traditional web applications, i.e. sending HTML over the wire. We will learn about them in the following posts in this series.
- 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.
- Turbo Frames divides pages into independent contexts called frames (not iframe). Turbo captures link clicks and form submissions inside a frame, automatically updating the frame contents after receiving a response.
- 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 of fast performance. When you need additional responsiveness, you use Turbo Frames, and finally, a few cases where you need to bring your application alive, such as sending live updates from the server, you will use Turbo Streams.
We will learn about all these techniques in future posts (as I learn them myself 😅 ). For now, 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.