Hotwire And React And Ecosystems
Previously on Locally Sourced: I said this one would be about interview code, which it isn’t. Next time. Meantime, the live home of this newsletter is https://buttondown.email/noelrap, where you can subscribe for free, or for money if that’s feasible for you and you are so inclined. Thanks, and tell your friends!
People have been asking me quite a bit recently whether I would choose Hotwire or React for a project and what role each has in the web ecosystem. And when I say “quite a bit”, that’s a literary device, I’ve been asked like three times this week though, which is a lot for me, I get a lot less feedback on this kind of thing than you might think.
This is a case where the question I can easily answer – what would I, Noel Rappin of the Chicagoland Rappins, do on a project that I controlled and knew I’d be working on – is not quite the question people want answered. People want to know what they should do in general. But the general answer is, “it depends”, which people never find satisfying.
Let me start with the easy answer.
I enjoy working in Ruby, and I enjoy working in Rails. I think that both of them give a tremendous amount of leverage for a small team. Hotwire lets me basically do Rails stuff, but makes the Rails stuff much more powerful for client-side effects. For me, for my projects, I’m going to run that into the ground. I’m going to use it until I hit a wall, and then I’m going to try and dig under the wall.
Stimulus is maybe my favorite web tool to work with. It’s simple enough that I could explain it to you in five minutes, powerful enough to run a whole client side web site, and flexible enough to do some very general and meta things. It fits the way my brain wants to think about JavaScript and the DOM. It’s going to take a lot to convince me that I’m running a project that it can’t handle. (And it’s going to take an awful lot to convince me that I need a single page app.)
I thing Turbo Frames and Turbo Streams are very powerful, and I like them, and they are just slightly not quite aligned with my mental model yet (I actually think this will get better over the next year or so as people use Turbo and the rough edges get sanded off). Often, my problem using Turbo is that I am trying to make things too complicated, when a simple form submit would do. I think that encouraging simplicity is a good thing in a tool.
That’s me. You are, presumably, different.
I can’t really tell you what to do. I can only tell you what I think goes into the decision.
If you and your team are more comfortable with Ruby, that tends you toward Hotwire, if you are more comfortable with JavaScript, head toward React or one of its ilk.
I honestly don’t think the complexity of the application as a whole makes much of a difference, but the complexity of the client-side does. The easier it is to imagine the client interaction as a series of basic web navigation and form submits, even if those transitions only change part of the page, the more compelling Hotwire is. The farther you are from normal web navigation (like, for only one example, a game) the more compelling a React solution is.
In particular, the more state the client side has that the server doesn’t care about, the more compelling React is. What you don’t want to do is spend a lot of effort building a SPA just to replicate web navigation, which I promise you is a thing that browsers can do pretty well already.
You’ll often read that if you are going to have multiple clients (like a browser and a native app), then you should do a server API and client side SPA. I get the logic there, but I also think that you can do a native app that is mostly a browser window and it works fine. I’d say that if it makes sense to have a full API for other business reasons that might push me toward a client-side app, but I’m not sure I’d build an API just to have both a native and browser app – my suspicion is that you are adding complexity for not much payoff.
Picking a tool that your team is excited about using is a factor. If your team is all JavaScript people that don’t like using Rails, than Hotwire is probably not for them, (I realize that Hotwire has been ported to non-Rails server side tools…)
You’ll often read that performance is a reason to choose a client-side tool like React, on the plausible grounds that many client interactions can show results to the user without waiting for a server. My instinct here – which could certainly be wrong – is that this sort of true for some things that don’t require server data to update the page but probably less useful in practice than you might think. For one thing, the React app still does need to talk to the server, and for another the React app is probably requiring a much bigger payload to the browser on first request. I’ve used enough client-side apps that nevertheless feel sluggish to be dubious that this universally true.
An argument you’ll see that I mostly agree with is the idea that SPA’s are more suited to a large team because of their added complexity. I’d interrogate that a little more though, to wonder why I’d use a tool that is that complex by definition, even if I have a large team to absorb the complexity.
Pretty sure you disagree with me about one or all of these points. The live home of this post is http://noelrappin.com/blog/2021/04/hotwire-and-react-and-ecosystems, leave a comment and tell me where I’m wrong. Also, tell your friends to subscribe at https://buttondown.email/noelrap.