“Hotwire’s combination of Turbo and Stimulus deliver all the tools needed to produce fantastic user experiences that leave little to nothing on the table in contrast to single-page applications – at a fraction of the complexity.” - DHH
In larger companies, the issues associated with utilizing a SPA front end with an API back end is more manageable because larger companies can afford larger teams. Often, it makes sense to break up larger development teams into smaller cohesive units allowing them to work together on creative solutions to customer issues. You have them talking to your customers, right? On smaller teams, such as a successfully bootstrapped SaaS, a front end team, backend team, and mobile team can be a strain. Even if you are a big company and can afford larger teams, wouldn’t it be nicer to do more with less and potentially have happier Rails developers? There’s a strong possibility that you will be able to turn around features for your client base faster than you are now.
Separate front end and back end teams is overkill if you can successfully deliver the same features at the same fidelity with a full stack Ruby on Rails team. What if your app supports mobile? Your overall complexity is even higher. With Hotwire, you can reuse some of your web functionality in your mobile app through Turbo, a hybrid solution that we are seeing good results with. The support for this in Hotwire is decent today, but should be even better with Strada. If you are unfamiliar with a hybrid mobile solution, essentially you build native views in iOS or Android for you the workflows your clients use most, typically starting with your navigation, and leaving less utilized pages such as user preferences as web views rendered inside of your app. Another positive of this path is that you can do a lot of adjusting and upgrades to the mobile app itself without having to resubmit to the Apple App Store or Google Play. Authentication and push notifications are key areas here that are most likely going to be built using native iOS and Android techniques. Jumpstart iOS and Jumpstart Android are great resources to help get started here.
Having shared some of the positive results we have seen leaning into Rails 7, what can you do to take advantage of these changes? I suggest that your team find a small project that can be built in Rails 7. Let them use investment time or time that might be set aside to build an internal tool. I think they will enjoy the experience and you will all get a feel for the simplicity and speed of delivery. Next step would be to map out how best to migrate some products away from SPA to a full Rails stack. In a lot of cases, that is still a large problem to take on, but if you think ahead to a time where you may have to take on a larger company initiative, it might be worth weighing the time saved for delivery being worth the time investment required to make the shift from SPA + Rails backend.
If members of your team are completely new to Rails 7, here are some resources they should check out to gain some knowledge:
As DHH initially spoke of this new magical framework on Twitter that they used to build Hey, we were skeptical. As with all new technologies, Hotwire is still new and the supporting documentation needs improvement in some areas, but we have tried Hotwire on for size and are extremely happy with the results we have seen. We will be building a lot more with Hotwire and I hope I shared some convincing thoughts that might drive you to consider giving Hotwire a try.
Wouldn’t it be nice to “produce fantastic user experiences that leave little to nothing on the table in contrast to single-page applications – at a fraction of the complexity.” - DHH