Real life application with Rails and Stimulus Reflex compared to the SPA approach

Hi Rails and JS devs,

I never really understood the hype around SPAs and "modern JavaScript" development workflow.

It always seemed so much complicated to me for basically no real advantages.

I will talk about it more precisely in a future blog post.

So I created a repo with the two stacks to compare how much they are different in a real life scenario.

Turbolinks was a game changer and Stimulus Reflex adds the last thing to create reactive apps.

Here's the repo: [](

Let me know how do you build reactive apps these days!

4 thoughts on “Real life application with Rails and Stimulus Reflex compared to the SPA approach”

  1. Well done, i started with Rails+jQuery then Rails API + React and now using StimulusReflex and i’m enjoing it. Having all done with Rails is super simple, still learning but i think I will stay with StimulusReflex for now.

    which one do you prefer (when both are an option)? main differences for you?

  2. One thing that caught my eye recently is htmx (the spiritual 2.0 of intercooler). It’s sort of like render_async gem (, but you don’t need to write any new ruby conventions. it also has experimental support for web sockets.

    I’ve always hesitated to add a websocket server to my infra b/c it’s just another thing that can go down. Especially if you use stimulus reflex, if your server goes down, can it really just operate with http?

  3. > basically no real advantages

    What? Being able to completely separate your concerns is invaluable when dealing with larger, segmented development teams. Deploying your entire frontend on S3 and putting a CDN in front of it is pretty great too.

    It’s unclear if you’re trying to preach to a choir or simply haven’t done much research on the topic, but SPAs have quite a few advantages.


Leave a Comment