00:00:04.600
Good morning! Today, I want to talk about Hotwire and the landscape after Turbo 8 was released. I'm super happy to be here at Helvetic Ruby in my home country to actually give a talk in person, which is awesome!
00:00:11.880
Earlier this year, we got the Turbo 8 release, and this kind of changed what was happening in the Hotwire ecosystem, at least from what I am seeing. If you haven't met me, I'm Marco. Nice to meet you! If you have any topics you'd like to discuss about Hotwire, feel free to find me after the talk.
00:00:29.640
I've been part of the core team for Stimulus, StimulusReflex, and CableReady over the past few years, and I’ve been maintaining Stimulus for quite some time as well. So, it’s safe to say that I kind of love open source, and I’ve had an awesome journey in open source thus far. I have been working in open source since 2019 and became part of the Hacktoberfest program back then. Since then, I've really enjoyed it, especially when I went full-time in open source to work on Hotwire and related technologies in 2022.
00:01:10.159
I've also started contracting last year to continue working on open source at least part-time. I love Ruby and I also love Rails, and I want to keep building Rails applications with Hotwire. I feel like the combination of Rails and Hotwire is kind of a superpower, especially if you pair it with Rails. The stack is really awesome!
00:01:31.360
You get to work on the stuff you already know and love while building more Rails applications. Personally, that's the future of modern Rails apps. With Rails 7, we got kind of halfway toward the vision of achieving an awesome state where Hotwire is built into the framework by default. In my opinion, this has fueled the resurgence of Rails that we have been seeing over the last few years.
00:01:47.880
There has been a lot of hype about Hotwire and Rails again, partly due to Hotwire’s success. Working with StimulusReflex has been really smooth, fast, and enjoyable, and it felt like Hotwire was this missing piece of the puzzle that could make Rails this full-stack framework worth using again. As an open source enthusiast, I want to make Hotwire the best framework it can be—accessible and approachable to everyone.
00:02:14.680
This is especially important during a time when we have this hype going on. I want to build modern tools and front-end solutions to make modern Rails applications that are worthy of the Rails framework and its history. Earlier this year, we got Turbo 8, which introduced a bunch of new features, including morphing, page refreshes, view transitions, and more! For me, this changed the trajectory of the framework quite a bit in the ecosystem.
00:02:59.280
So, what is Hotwire? It’s an acronym for HTML over the wire. The idea is that we want to use HTML as the format for our applications. The server is the single source of truth, and we want to build our business logic on the backend while writing HTML. We aim to avoid duplicating any logic on the front end while building our applications.
00:03:19.120
Hotwire is not about getting rid of JavaScript; rather, it’s about reducing the amount of JavaScript that is needed for your application. We want to minimize application-specific JavaScript. But how did we get to this point? I want to talk about the timeline of history to understand where we are now.
00:03:37.560
In 2012, we introduced Turbolinks along with Rails 3.2. By 2013, we had Turbolinks enabled by default in Rails 4. Turbolinks aimed to make web navigation faster by preventing the reevaluation of scripts and stylesheets on every page navigation. This was also a time when many of us were using Rails and skipping Turbolinks because nobody truly understood what was going on. I think Turbolinks was ahead of its time by about a decade! In 2016, with Rails 5, we got Turbolinks 5, which changed the way we worked with it quite drastically.
00:04:23.600
If you haven't seen the talk by Sam Stevenson, I personally enjoyed it the most, as it really captured the essence of what Turbolinks offered. It introduced a way to create native apps using hybrid applications by allowing one backend app that could also be used for mobile apps. At that time, we were still heavily using jQuery to make things work, often hacking our way through.
00:04:52.400
It was quite confusing, especially when I struggled to know how to reinitialize components with jQuery. This led to the inception of Stimulus in 2017, which kind of helped with that by giving us lifecycle hooks to work with. We knew how to reinitialize those components with it. At that time, we also received CableReady in 2017, which was the missing piece we needed for building more sophisticated Rails apps.
00:05:21.920
We wanted to build more advanced Rails applications with a front end that truly integrated with the Hotwire approach. We were missing the concept of building reactive applications in Rails. In fact, we aimed to develop reactive, real-time, and high-fidelity applications, which is why in 2018, we got Phoenix LiveView and StimulusReflex.
00:06:10.360
Phoenix LiveView is a library for Elixir, whereas StimulusReflex is the equivalent for the Rails ecosystem. Its idea was to enable us to build reactive Rails applications using the Rails tooling we already knew and loved. In 2018, we began utilizing Rails, Stimulus, Turbolinks, CableReady, and ActionCable to make that work.
00:06:43.160
Here’s a simple example of what that looked like back then. We had a button where we would add data-reflex attributes and specify that we wanted it to listen for click events. Whenever we clicked, we wanted to refresh the time displayed on the screen. By simply annotating it, we defined how to rerender the application and update its state.
00:07:06.580
Here’s a more advanced example— we have a counter controller where we set a count instance variable to either the session value or zero. In our view, we would also add data-reflex attributes. When we listened for the click event, it would call the counter reflex to either increment or decrement the count value. Next to it, we would render the current count value.
00:07:52.640
With this setup, we achieved a count component that could count up and down, but we also had only the reflex part, which dealt with incrementing or decrementing the value. StimulusReflex autonomously knew how to rerender the application without any intricate logic or route definitions. It was incredibly smooth; it just understood how to update the state without extra annotations.
00:08:26.960
A few years later, we saw the release of Hotwire and Turbo in 2020, introducing Turbo Drive, Turbo Streams, and Turbo Frames. This evolution played a significant role in shaping StimulusReflex and the whole concept. By 2021, we had Hotwire as a default integration in Rails with the release of Rails 7, and this year, we got Turbo 8, which introduced morphing capabilities with Turbo page refreshes and Turbo model broadcasts.
00:09:15.680
There are many terms in this arena, and I assume most of you are familiar with these concepts, but if not, I’ll try to visualize it a bit in a graph to illustrate what’s been going on. On the left side, we see the basic stack we had in 2018 where StimulusReflex and the Rails stack were pretty much aligned until we started adding some enhancements to make it work and be reactive.
00:09:48.200
As Turbo advanced, we added more tools, and now, in 2024, we have filled more of these boxes, leading us to a point where our paths are converging. We share a common goal of making applications simpler and easier to work with while also wanting to build unified applications. Hotwire is now integrated by default in Rails.
00:10:27.200
We need to reevaluate what we're doing with StimulusReflex and how we want to proceed going forward. We recognized that there is some overlap, and we want to invest more time into making Hotwire a better solution for everyone.
00:10:40.760
The question arises whether you should start new projects with StimulusReflex today. My answer, which might be controversial, is probably not, but not because it isn’t good enough or advanced enough. Rather, I think it’s still ahead in some ways compared to what Turbo offers, but the way we work kind of makes it hard to develop new apps straightforwardly with StimulusReflex.
00:11:02.520
Hotwire has evolved significantly over the years. Despite their similarities in final goals to facilitate development for everyone, these two projects are somewhat competing with each other. Many people are confused about the project boundaries and overlap, which complicates things further. I've seen a lot of confusion about what exactly StimulusReflex is.
00:11:39.080
Last year, we released CableReady 5, which was the biggest release thus far, and we also launched StimulusReflex 3.5 recently. This release was a culmination of three years of work that aimed to adapt to Hotwire functionalities in a way that meets user expectations.
00:12:08.720
We don’t plan to introduce new features for StimulusReflex in the near future. Instead, we will dedicate our resources to enhancing Hotwire for better overall functionality. For example, there was a version called Turbo Boost that aimed to integrate all the concepts from StimulusReflex directly into the Hotwire ecosystem. However, attempting to standardize everything created more confusion.
00:12:45.840
Our focus going forward will be on improving the Hotwire ecosystem to ensure it becomes the best framework in the space for building Rails applications. StimulusReflex has inspired a variety of features currently present in Turbo, and many of these features have roots tracing back to what we have done in StimulusReflex.
00:13:20.160
It’s crucial to recognize that we’ve pushed the boundaries of HTML over the wire through community effort. It’s not about blaming anyone for the pace of development on the respective teams. It’s about showcasing how much we, as a community, can achieve when we collaborate to innovate.
00:14:04.960
What have we learned from this experience? I believe we need a more formal organizational structure to drive and progress the Hotwire development efforts. There are several essential aspects to consider, including documentation, marketing, and tooling. It's safe to say that we can enhance each of these areas through greater community contributions.
00:14:48.040
There are numerous open issues and pull requests on these repositories that highlight the community's need for improvement and engagement. At present, Hotwire is still in its infancy compared to what we see with Stimulus and Turbolinks in Rails, yet there's no dedicated Rails core team that guides the direction and installs for Hotwire.
00:15:14.880
Rails has thrived due to the myriad of companies pushing it over the years, while the diverse set of contributors nurturing the Rails ecosystem has been essential. We want to create a similar community for Hotwire, hence it’s important to form a dedicated team or group that propels Hotwire toward a unified development effort.
00:15:47.880
What can we take away from StimulusReflex? There are several features present in StimulusReflex that have not yet transitioned to Turbo, including enhanced developer experiences, installation easiness, and partial page updates. We need to ensure that these features benefit everyone in the community.
00:16:11.960
Moreover, we need more advanced use cases and diverse companies developing with Hotwire so we can showcase what is truly possible. Many people are unaware of the capabilities of Hotwire because they lack knowledge of what exists in this ecosystem.
00:16:35.040
For those companies that are migrating to Hotwire, we need to better represent their needs in an official capacity. Better documentation and Rails integration are essential as a large number of developers are building applications using Rails.
00:17:09.760
As for me, I want to continue to build full-stack applications using Rails, and I believe Hotwire should enable that. So, with all that said, I want to discuss the ecosystem and what constitutes a great ecosystem.
00:17:51.680
In my opinion, a great ecosystem includes more than just frameworks and technologies. It's composed of comprehensive ingredients that allow things to work smoothly, including tools, documentation, and community engagement.
00:18:26.640
Let’s talk about tools. By tools, I mean aspects that enhance developer experience such as editor tooling and browser extensions. Developer experience improvements across Stimulus have proven beneficial. For instance, if you have a user profile controller with a simple connect method, when you add the data-controller to your HTML view and expect to see that invoked, it may not work due to naming conventions.
00:19:04.560
These mistakes are easy to make, yet I believe we can do better. I've been working on a tool called Stimulus LSP, which works with various IDEs including VS Code, RubyMine, and Sublime. This tool provides completion for all the controllers in your application and helps ensure proper implementation.
00:19:48.200
It notifies you when you've misspelled a name while also offering suggestions for the correct identifiers. If you create a new controller that does not yet exist, it provides a quick fix to create it in the correct format. We implemented these features to enhance the experience while working with Stimulus.
00:20:31.040
The results of these efforts have contributed to the complete overhaul of the Stimulus parser, which now tracks all classes in your project and accurately maps imports and exports. This is aimed at providing more accurate results and recommendations. Furthermore, we’re also focused on allowing for dynamic registration of control identifiers to avoid confusion.
00:21:14.520
This tool is part of a larger vision wherein our goal is to support Rails tag helpers and enhance interaction with import maps. We strive to add more diagnostics to further streamline the coding process with Stimulus. As of now, we have shipped various key features to improve usability.
00:21:58.640
Looking ahead, we want to focus on Turbo LSP, which still needs some work before it can be fully functional. Our vision includes browser extensions for both Stimulus and Turbo to enhance operational efficacy. Working with StimulusReflex for interactive page elements has been a step in that direction.
00:22:34.720
When you toggle these interactive parts within your Hotwire applications, it allows you to pinpoint the components that trigger events and understand the re-render behaviors. Such tooling boosts productivity and makes it easier for developers to implement changes quickly.
00:23:14.080
The next aspect I want to address is documentation and community engagement. I’ve spoken to several contributors and developers working with Hotwire, and they have expressed their desire for more comprehensive documentation— especially tutorials and how-to guides that are readily available.
00:23:53.080
In an effort to address these gaps, we have established the Hotwire.io initiative. This community-driven documentation hub aims to showcase frameworks, tools, guidelines, and community resources to help everyone navigate the ecosystem.
00:24:30.760
There are many frameworks that could greatly benefit from this collaboration between the community and documentation initiatives. I believe we need to build a more comprehensive JavaScript ecosystem for server-rendered web applications.
00:25:07.760
So, Hotwire.io also includes sections categorizing libraries, which help users find good integrations for Hotwire. We aim to facilitate connections within this community to present resources for developers looking to enhance their understanding and application of Hotwire.
00:25:47.600
To guide users on which technologies to adopt, I envision an interactive setup guide. Users would be able to walk through their preferences and requirements to receive personalized recommendations on which tools to utilize for their applications.
00:26:16.600
I’m enthusiastic about working toward this vision alongside continuing improving Hotwire and Turbo. As Hotwire matures, I aim to ensure that these tools address the needs of our community.
00:26:44.720
It's essential for us to better accommodate companies migrating to Hotwire. Therefore, there is a growing need for better React compatibility and gradual migration paths, rather than a one-size-fits-all approach.
00:27:17.520
As we continue to refine these patterns within the Hotwire ecosystem, we must maintain focus on constructive developments. To me, that means continuing to push for unified solutions in building Rich Applications with Rails.
00:27:48.200
I’m committed to advancing this cause, including developing reactive applications with Hotwire while preserving the tooling familiar to developers. Thank you all for your time today and for supporting the evolution of the Hotwire framework.
