Previously on Locally Sourced: Rails came out and let people do Ajax, when Ajax was a thing. Then Ajax was less of a thing and Rails let people write CoffeeScript, and use Sprockets. Also, I wrote a book on Modern Front-End Programming with Rails, which is relevant to this edition.
Rails 5.0 introduced Rails API and ActionCable. I don’t have much to say about ActionCable except that it seems to basically work and using it is not my favorite developer experience. Rails API is a minimal version of Rails with no view code designed as a server-side for single page apps and mobile apps. It has a bit of a history in that it was an actual fork of Rails for a while before being incorporated back into the main repo. If I’m remembering correctly, the API version was added into Rails in the 3.x or 4.x time frame and then removed by DHH, which triggered the fork, and then the re-incorporation. I’ve never used it in a production project, but I think Rails is better served by having it as part of the main project rather than a fork.
I basically like Webpacker, but it’s a little too fickle for it to be in my “I love it, it just works” category.
The main upsides to Webpacker:
- Reasonably low bar to get started on in the simple case.
The main downsides to Webpacker:
- Especially early on, delivering CSS and static assets via Webpacker was complicated, leading many teams (including Basecamp itself) to use both Webpacker and Sprockets. This seems objectively over-complicated.
- I worry that, like Sprockets, it’s a little under staffed relative to webpack and will continually be playing catch-up to new versions.
- It’s a pretty leaky abstraction, and eventually, you do need to learn some webpack if you want to do anything complicated.
Cards on the table here, I really, really like Stimulus. I’ve been successful with it, I like the philosophy behind it, and I think it’s admirably not-complex and has a very strong “it just works” vibe. I’ve thrown some weird dynamic stuff at it, and Stimulus handled it just fine.
Stimulus encourages a much different design structure than React. Although you can build reactive behavior and external state into Stimulus, you’ll reach a point where you are building a half-assed version of React and it’s going to feel awkward. Stimulus is usually better served keeping state in HTML data and handling reactive changes differently (with CSS, or with going back to the server for more HTML).
Honestly, the whole JS book would be Stimulus, except that Stimulus isn’t that big, and also that adding React more or less opens the book to about 10 times the potential audience. I have nothing against React – I quite like it in small doses, though I think a lot of SPA React code is more complicated than it needs to be. If the book gets a lot of people to read it because of React and a bunch of them discover how easy Stimulus is, I’d be thrilled.
Which brings us up-to-date, with new tools alluded to but not released, next time, I’ll talk about them a little bit.