Maybe you can with heroic effort, but you shouldn't. You should build within the constraints of your tools. HW + Stimulus are great - good enough for what most web apps need to do. It gives you "traditional web app, with a bit of realtime updating" - which is the perfect fit for most web apps.
But you wouldn't want to use it for a fully interactive desktop style application with lots of interacting components.
Agree. So unless you have a pretty big budget and you're building Google Maps or Figma you shouldn't use React.
Sadly, everyone things they have such a big budget and they're building the next Figma. Even if you're building a CRUD app. (I'm talking to you previous team of mine).
You can do anything with plain JS too, but that doesn't mean you'd want to. The problem with Hotwire is that you do often have the server round trip in there. That's fine most of the time, it just gets a little harder to understand as the complexity rises. That's not to knock it, I think Hotwire is pretty good.
In what scenario would complexity be higher in a simple UI - server loop? Doesn’t complexity usually arise from having additional logic in the browser and maintaining state separately?
I guess it depends somewhat on how you imagine up something and write it. I was working on some drag and drop UI that had multiple sortable lists and an action area. Figuring the server side and UI at the same time didn't work out. I reversed and implemented the UI with its required state, and then it was easy to transform that state to what the server side required, and vice versa.
Complexity is tricky. Are three simple things more complex than one thing thats harder to understand?
You can still use React or whatever on those pages. And for the rest (settings pages, signup pages and all the CRUD pages) you can use standard Rails with Hotwire.
But you wouldn't want to use it for a fully interactive desktop style application with lots of interacting components.