Hotwire: First Reactions
Published: December 26, 2020
Hotwire is a set of libraries and conventions that does for single-page interactivity on web sites what Rails did for web applications.
It provides all the benefits of client-side single-page application (SPA) frameworks with almost none of the downsides.
Benefits of an SPA
All the benefits of a single-page app come down to different aspects of the same thing: reactivity.
When the user performs an action, the application reacts immediately, without the delay of an HTTP request, page download, render, and state reset.
When there is a change in application state that is not a initiated by the user, the change is immediately visible to the user without needing to click, reload, or wait for the page to download and re-render.
Downsides of an SPA
The downside of SPAs is that they are complicated. That complexity results in several times more work for developers, while simultaneously breaking functionality that is included automatically with HTML pages.
Users have to wait for the JS bundles to download and initialize before the application first begins to render. Then while using the app, they find that the web browser navigation buttons (back, reload, forward, etc.) cause the app to break or reset. URLs cannot be used to point to specific parts of the application, making bookmarks useless. Worse still, keyboard navigation, screen readers, and other assistive technology are often broken. And if you are running an uncommon browser or older hardware, you may not be able to use the app at all.
All of this could be fixed or mitigated with sufficient care and effort from the developers, but none of that work is necessary for web applications serving HTML and CSS.
Meanwhile, developers are also dealing with other added complications.
There are two main libraries that make up Hotwire, Turbo and Stimulus.
Turbo takes the strategy a step further and provides tools to update parts of the page in response to user action or live updates broadcast over a WebSocket.
How Hotwire works
Probably more important than the libraries that make up Hotwire are the conventions on how those libraries interact.
The most important of these conventions is the one that gives Hotwire its name, HTML over-the-wire.
Downsides of Hotwire
There is no silver bullet; even Hotwire has its downsides.
Hotwire is a new framework. It hasn’t been proven in a lot of applications and no one outside of Basecamp has a lot of experience with it.
However, Stimulus is proven technology that’s been around for years. Turbo evolved from Turbolinks which has been a part of Rails since 2012.
And all of Hotwire is in production at Hey.
Hotwire with Rails is built on an extensive set of conventions that allow the different parts to work together. If you do not follow these conventions carefully you will end up with a hairy mess of spaghetti code.
Once these conventions are well-understood and strongly modeled, they are easy to follow; but until then there is significant risk of making your code confusing and buggy.
Hotwire is a huge improvement over SPA frameworks, but it is still complicated — really complicated.
Other SPA framworks have the same problem. The best way to mitigate it is with strong, simple conventions that give you a lot of confidence that the integration works, so few integration specs are needed.
Hotwire provides an HTML/CSS-centric way of creating live and reactive web applications. I believe it will revolutionize reactive web apps the same way Rails revolutionized web apps.
I highly recommend learning about it and adding it to your tool belt. Anytime you want to improve a portion of your web app by making it more instant and reactive, Hotwire is the tool to reach for.
The smart thing to do is add Hotwire little by little to places where it will have the biggest impact. But the technology is so exciting, I am considering rewriting entire applications to take full advantage of it.