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.
“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?
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.