Hotwired ASP.NET Core Web Application (6 Part Series)
Hotwired ASP.NET Core Web Application — Part 1 (Intro)
Hotwired ASP.NET Core Web Application — Part 2 (NPM, Webpack Setup)
Hotwired ASP.NET Core Web Application — Part 3 (Turbo Drive & Frame)
Hotwired ASP.NET Core Web Application — Part 4 (Turbo Stream)
Hotwired ASP.NET Core Web Application — Part 5 (Stimulus)
Hotwired ASP.NET Core Web Application — Part 6 (Quote Editor)
After developing single-page business web applications with ASP.NET MVC on the backend for more than ten years, we decided to try a new path when we were introduced to the Turbo and Stimulus components of Hotwire approach, by the awesome Ruby developers of Lab2023.
Aside from the common downsides of an SPA architecture, we were mostly content with it. However, when we started developing it, we didn’t take into account that it had to be responsive. So, when we needed to support mobile devices, we either had to rewrite it or develop another application for mobile devices. Rewriting using the same JS library as a PWA had so many unknowns, and we also weren’t sure that it would satisfy the needed user experience. And in small teams like ours, it is almost impossible to have two development teams to build two fully-native versions of the same application for Android and iOS. In the end, we decided to use Xamarin, which enables creation of a core codebase that can be used across all platforms so, eliminating the necessity of two specialized teams for us. So far, Xamarin did its job. But submitting the new version of an app to the app stores and waiting for them to be released, especially if the release will fix an important bug, no matter how fast the process gets, is still tedious and slow. We long for the way we respond to bug fixes in our web application. Moreover, as we had struggled in SPA, being tied to a JS library or an uncommon framework, makes it hard to feel safe when the developers quit your small team. In the end, we knew the inadequacies of our ways and we knew how we wanted it to be. But, until we were introduced to Hotwire approach, we didn’t know it was possible.
Hotwire
Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire.
At the core of Hotwire approach is Turbo, which handles at least 80% of the interactivity that would normally require JavaScript to reach to the speed of a single-page web application. While doing that, it also allows us to keep our business logic in one place, on the server. So, in contrast to traditional SPAs, which manipulate the DOM with a complex client-side JavaScript library and only communicate with the backend through a JSON API, Turbo based web applications leave the HTML rendering to the server-side and send HTML instead of JSON over the wire, without losing any of the speed or responsiveness of an SPA.
The second component of Hotwire is Stimulus, a simple, tiny JavaScript framework that aims to deliver the rest of the interactiveness on the server-rendered HTML. So, unlike the full-fledged frontend JavaScript libraries that handle all DOM manipulations, Stimulus does not render HTML: it only connects JavaScript objects to elements on the page using simple annotations.
The third component of Hotwire, Strada (which hasn’t been released at the time of writing this article), aims to conventionalize the communication between HTML and the native app. Since it is not yet released, there isn’t much information about it. However, it is not an essential component to develop hybrid mobile applications with Hotwire; it will just make things easier. To develop native apps with Hotwire what we only need are the native adaptors.
Getting Started with Hotwire
As I mentioned before, Turbo is the core component of the Hotwire approach and it is created by the team behind Ruby on Rails. However, although it is not Ruby on Rails specific and can be integrated with other backend frameworks, there aren’t many implementations outside of the Ruby world. For us, the backend had to be the latest ASP.NET Core Razor Pages or MVC; it was not possible for us to switch to Ruby. We could only upgrade our backend from ASP.NET to ASP.NET Core. And when we searched for an implementation that would help us to grasp Hotwire approach in the .NET world, we found almost nothing.
During the training we got from Lab2023, they used the “The Turbo Rails Tutorial” to explain to us the functionalities of Turbo and Stimulus. It is a comprehensive tutorial, with excellent step-by-step explanations. However. again, it was in Ruby on Rails. And this is when I decided to port this tutorial to ASP.NET Core. It was a good exercise for me to get familiar with ASP.NET Core and to fully understand and figure out the implementation of Turbo and Stimulus in ASP.NET Core.
In my following posts, I will explain in detail how Turbo and Stimulus work while using them in an ASP.NET Core web application, which you can access the final version from here. However, to use these packages, we need to set up our development environment using NPM and webpack. And since .NET mostly uses the NuGet package manager, I decided to explain this integration also in detail in the next article. If you are comfortable using NPM and webpack, you can skip it and continue with Part 3. Also, I strongly advise reading the Handbook and Reference sections of Turbo and Stimulus documentations: Every concept is clearly explained and easy to understand. In my articles, I will focus on the implementation in ASP.NET Core so knowing the concepts beforehand, will make the rest of the tutorial easier to follow.
References
[1] Hotwire
[2] Turbo
[3] Stimulus
[4] The Turbo Rails Tutorial
[5] David Heinemeier Hansson answers our questions about Hotwire
