Rails, Hotwire, CableReady, and StimulusReflex are BFFs
Tags: rails, hotwire, stimulusreflex, cableready
Published: 2021-11-08 16:27:46

---
title: Rails, Hotwire, CableReady, and StimulusReflex are BFFs
published: true
description: Using Hotwire, CableReady, and StimulusReflex together is a power move that will improve your apps
tags: rails, hotwire, stimulusreflex, cableready 
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2awmgn49tmvea2zll4zp.jpg
---

**Enforcing strict RESTful routes and controllers is perhaps the most impactful technique that influenced my usage of [Ruby on Rails](https://rubyonrails.org/) for the better.** I cannot overstate how much I love traditional [REST](https://en.wikipedia.org/wiki/Representational_state_transfer) semantics and encourage their usage on every team that I have influence over. 

Having said that, I also think rigidly applying this pattern to smaller and smaller use cases has diminishing returns. One example of a smaller use case is [TurboFrames](https://turbo.hotwired.dev/reference/streams). TurboFrames are great and I use them along with their attendant REST semantics, but I try to be very thoughtful about how far I take this approach.

For example, libs like [CableReady](https://cableready.stimulusreflex.com/) and [Futurism](https://github.com/stimulusreflex/futurism) can lazy load partials so unobtrusively that the notion of adhering to the formality of REST, _with the required new routes, controllers, etc..._, would be far too much ceremony for such small use cases.

One of the original goals of CableReady and [StimulusReflex](https://docs.stimulusreflex.com/) was to work seamlessly with traditional HTTP server rendered Rails apps _(pre Hotwire)_ without requiring significant architectural changes or forcing a proliferation of new routes, controllers, or views/partials etc... We basically wanted a way to gradually introduce robust real-time and reactive behavior into traditional Rails apps with as little friction as possible. The idea being to allow people to leverage the work that had already been done rather than forcing a rethinking of the app. I view CableReady/StimulusReflex as: **REST + [RPC](https://en.wikipedia.org/wiki/Remote_procedure_call) sprinkles + async server triggered DOM behavior**.

[Hotwire](https://hotwired.dev/), while very cool, introduces new concepts that impose a higher cognitive cost and forces you to rethink how to best structure a Rails app. I view Hotwire as: **REST semantics for everything + async server triggered CRUD updates**.

There are pros and cons to each approach. Hotwire has more obvious and strict conventions, while CableReady and StimulusReflex adhere more to Ruby's philosophy of flexibility and expressiveness.

For me, using both Hotwire and CableReady + StimulusReflex techniques together is like _["having my cake and eating it too."](https://en.wikipedia.org/wiki/You_can't_have_your_cake_and_eat_it)_ Admitedly, this is a power move and requires some experience to know when to apply each approach.

FYI - There are some great conversations on the [StimulusReflex Discord](https://discord.gg/stimulus-reflex) server about this stuff. We'd love it if you joined us.

---

Also, I should note how much I dislike the umbrella marketing term **"Hotwire"** as it forces a false dichotomy in this conversation. Both CableReady and StimulusReflex are designed to work well with Hotwire libs and even have hard dependencies on some of them.