Hacker News new | ask | show | jobs
by fishtoaster 1272 days ago
My impression is that there are two ways to use rails:

1. Your frontend js needs are pretty minimal and you don't want something approaching a single-page app. In this case, you lean into Turbo and Stimulus to have rails do most things for you that would previously have been done with some a heavy-weight react-based frontend.

2. Your frontend js needs are significant and you do want a single-page app. In this case, ignore/disable turbo + stimulus. Instead, build your rails app as just a json API and then have a separate project for your frontend built using a dedicated frontend build tool like vite/CRA/webpack/etc.

On one hand, I feel like the turbo/stimulus stuff is the rails community preferring to pretend that the JS world doesn't exist. On the other hand, maybe it's really just the rails world embracing the above dichotomy: they're tools for doing some light frontend work with no JS, and an acceptance of the fact that if you want an SPA, there are better non-rails tools that you'll wind up using anyway.

2 comments

My employer fits your first criteria precisely. Turbo and Stimulus provide exactly as much interactivity as we need. The appearance is that we're trying to avoid Javascript. The reality is that we are (successfully) minimizing context switching when working on the code base.
I think your point (1) doesn't really match with what the rails devs expect.

37Signals have both their Basecamp and Hey.com products which act very much like a single page app but only using Turbo and Stimulus.

I think the rails devs believe that single page apps are overused and the majority of functionality can be done using just the provided tools.

Yeah, the ruby community has a bit of an axe to grind with SPAs. Opinions range from the defensible ("JS is a bit overused, sometimes pure serverside rendering like Rails does is all you need") to the imo-ridiculous ("Pretty much no one needs an SPA and the whole frontend JS world is a passing fad").