Hi gang, I’m starting a new Rails project and was planning on using React for the front-end until I learned about Hotwire!
The most complex part of my application is a query builder. Crunchbase has one that’s publicly accessible here: Query Builder | Companies | Crunchbase
Can I build this query builder using Hotwire or will I run into challenges?
Thank you for the help!
Welcome! I think this is an interesting question. First of all, the Hotwire ethos is one of taking something that already works without any JavaScript, and layering over that the smallest bits that can turn it into a more pleasant and reactive experience for the user. Think removing full-page refreshes, while under the hood, all the interfaces that support doing [insert task here] with full-page refresh still exists.
I can easily imagine that query builder working (in Rails) as a set of nested forms, with a full-page refresh after each change. It would still work, just more slowly and with less user satisfaction.
So my answer would be yes – you can build something like this with Stimulus, and it can be just as (if not more) usable as a full-on React + API experience.
From a developer standpoint, it will definitely be much more agile and maintainable, since you would never need to work in two different code bases, or synchronize changes between multiple technologies and teams. It’s much more likely that a single developer could build a working example and iterate over its design.
Walter
Thanks for the quick response Walter! That sounds very promising.
What is an example of an application where Hotwire/Stimulus would fall short and where you’d reach for React instead?
I’m not a huge fan of React as a technology. I suppose the first thing that comes to mind is an application that needs to maintain local state in order to do its job, and has to be able to do that through network outages. But that would be a stretch.
The problem that React creates is one of state maintenance. In order to work, it needs a big corpus of data to act on, and in order to be fast, it only updates that data locally. Periodically, it reports back to the server. So you end up with the same information in two places, and occasionally that data is in agreement. That same problem creates an opportunity to weather a data drought without having to stop working. But if someone else updates that same data while the first person is offline, how do you reconcile those changes? It becomes a very hard problem, and ambitious Web apps are considerably more difficult than desktop or mobile apps already, even if you only keep state in one place rather than two.
The larger problem that React creates is one of having to build essentially two applications. One to feed it data and maintain security and continuity (an API), and then the other to run in the browser and show an interface to that data (React). And because that second part is running in the browser, you can’t trust it at all. Not even a little. JavaScript Security is like Military Intelligence in that regard. So you end up doing everything twice, re-validating data that the user entered and validated once in React when it comes time to insert or update in your real database.
Overall, if you really want to build something that looks and acts like Crunchbase, first try to imagine the simplest thing that could actually work. A form with a single field in it; when you make a choice, it auto-submits, and returns the same form with another field added to it, and so forth. So your only concession to JS would be that auto-submit on change. But everything else is just form elements submitting to a normal Rails app server, and a full page reload.
Once you get the logic to work that way, you can start to atomize it, pull that one big form out into lots of smaller ones, and start using Stimulus to manage the content updates and form morphing, so that it no longer has to work in only one direction. Then you can show the entire form at once, and no matter what changes are made in any part, the remainder will refresh as needed to show the responsive result.
Give it a try. It’s a refreshing way to think about the problem, and it means you only have to build that application once. After that, it’s a matter of refactoring to partials and adding controllers, not reinventing two applications in a tightly-coupled death march.
Walter