Hotwire vs React/Vue/Alpine/Whatsoever

Apart from the Turbo feature, is Hotwire able to tackle any state of the UI like any React-like JS framework does ? If the UI start to be really complex, wouldn't centralized state missing at some point ? Me : did a lot of Rails and JS, but very few Hotwire (tutorials mostly). What I can guess so far is that the JS framework will perform better in this area, but I'm looking for more experienced devs opinions who have both experiences in this area.
EDIT : I'm not only speaking about SPA vs non-SPA. Sprinkled VueJS amongst existing HTML could also work. Or maybe Turbo+AlpineJS.

13 thoughts on “Hotwire vs React/Vue/Alpine/Whatsoever”

  1. No. If you want high-interactivity front-end components you’re going to need to use a full fledged front-end framework. Hotwire works when you think of it as sprinkles on top of your server-rendered content. If you try to push it too far you’ll hit the boundaries pretty quick.

  2. I’m mostly working on backend applications. Not having a separate js frontend (and in many cases a separate frontend team, with Jira issues being split up) is such a bliss.

  3. I’ve been working with Rails since 2007 and picked up on the SPA train starting in 2012 with Ember and moved to React in 2015. I can say definitively that Turbo/Hotwire can tackle any user experience that React or any frontend library is promising you today.

    Performance is a relative measurement. For example, you can have high performant components and a low performing team that can’t meet the business demands. You can have a high performance team with low performant components that deliver poor UX. Turbo gives you the best of both worlds.

    1) Turbo fits right into monolith applications, especially Rails. This eliminates the need for devoting resources to build tooling, best practices, etc… When you adopt a frontend library, that isn’t Ember, you’re signing up for tackling architectural and development environment pains.

    2) Turbo has a simple paradigm that eliminates complexity you find with other frontend libraries. When we talk about React, we’re talking about an ecosystem beyond just React (routing, state management, networking, etc…).

    3) Turbo has a great developer experience. The docs are well written, the paradigm is easy to follow and ultimately requires less context – meaning more contributions that make meaningful impact.

    I can go on with reasons why Turbo’s paradigm will be the future of frontend development. It all comes down to eliminating complexity. In turn this cuts cost. Ultimately refocusing your team on delivering business value.

  4. To add to the other comments, SPA vs MPA, react vs Turbo is a false dichotomy. You can absolutely mix those and that can make a ton of sense.

    If you have one highly interactive, highly complex part of your application that needs to be super fancy. Then go ahead build that react app and mount it in the appropriate place in the dom within that MPA. Just because you need one highly interactive part, does not mean, your whole application has to be built on react.

  5. Stimulus has different approach to UI state than React, in general it wants you to keep it in the DOM. You can read more about it on the stimulus docs.

    But turbo replacing parts of your page means you don’t need to track state of UI that much.

    In other words: react solves problems that I see as largely self imposed by SPAs. Turbo seems to remove this problem instead of patching over it.

  6. > wouldn’t centralized state missing at some point

    What do you mean by this? It gives me an indication that you may have a misunderstanding about what hotwire/turbo is/does. It could also be a language barrier thing though.

  7. I’ve just recently build a fairly complex frontend feature that required real-time multi user updates in different languages at work using Hotwire/StimulusJS and I have to say that while initially I was super happy with how quick and easy I could get this to work, it’s now also causing quite some pain in terms of raw performance.

    I’d say that for a lot of use cases hotwire will make your live tremendously easier (e.g. with dynamically rendering new blog comments and such) than working with a full fledged frontend framework, but there’s definitely that kind of feature where I would consider it to be more benefitial to use some modern JS magic. And that doesn’t necessarily mean writing a full SPA application, that can also be solved by sprinkling in react/vue components where it makes sense.

  8. I’m writing an app for work (and a personal app as well) that uses Turbo and Stimulus and it works really well. You don’t need “centralized” state management because you have a “normal” multi-page app, like you had before SPA frameworks. Your state for a page exists in the DOM. Your state for an app exists in the DB.

  9. Yeah, sprinkled view-models (Vue, Svelte, whatevs) in places is the solution when you’re at that point where refetching a partial from the server doesn’t cut it.


    A mostly Hotwire app


    View-models in certain spots


    You need a way to glue those two realities. Wrap the view-model in a Stimulus controller. On \`connect()\`, instantiate the state from \`values\` properties passed in the DOM or fetch some json. On \`disconnect()\` make sure to save the state back into \`values\` properties for when it re-connects (say on a turbo:load from a back button operation). Voilà.


Leave a Comment