By Anton Pleshivtsev, Mofope Ojosipe-Isaac
I came across an interesting question about Hotwire in our previous post on Ruby on Rails in the US Market and I took this as an opportunity to give my perspective on Hotwire by describing the idea of sending HTML instead of JSON.
The question
“With the JS framework market leaning harder on SSR, something very easy to achieve in Rails, I am feeling like there is a Rails renaissance on the horizon with Rails 7. What are your thoughts on the Hotwire approach and the complexity for frontend frameworks to achieve the same results rails had always had?”
Before we go on, what is Hotwire?
According to hotwired.dev, Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This makes for fast first-load pages, keeps template rendering on the server, and allows for a simpler, more productive development experience in any programming language, without sacrificing any of the speed or responsiveness associated with a traditional single-page application.
Now, my thoughts
First of all, the idea isn't new. The famous book Agile Web Development with Rails was describing the same approach back in 2005 (I guess?). Yet the approach is still not mainstream.
Another good example that shows the approach has some issues is Nitrogen, the Erlang-based fullstack framework. The same beautiful idea: write code on a backend once, reuse it on a frontend. This was written in 2008 and yet again, it's still not widely used.
So what issues do I see here? First of all, it is still not a backend-only solution and you still need frontend developers. Even Hotwire's description says it covers only 80% use cases, if not less.
Secondly, the gem is still pretty new and you don't have a market full of Hotwire-familiar frontend developers so you'll have to invent something in the middle between hardcore Rails devs and Frontend-only engineers (which is not easy from my experience).
Finally, an issue that I see here (I can be wrong though) is the complexity of building modern UI patterns like optimistic UI. Since your UI changes depend on your backend/network performance you'll have to spend way more time to support exceptional backend performance (which, again, is not always easy).
In conclusion, I still want to play with this new gem and probably build some new product at Bravado using it to see its strong sides even though I have some concerns about its future.
