[marcosdumay]

> But Rails is supposed to be a giant

All the tools on the article are about client-side rendering and operations.

It's ok if Rails decided to have opinions on client-side rendering and operations now, but it's far from expected. And it would alienate some users.

Instead, the article's conclusion is the correct one. You don't need to mess with complex client-side and ops tools if you don't want to. You can build many things perfectly well without them.

[steveklabnik]

On one hand, I hear you, because Rails has focused on the server side.

On the other hand, Rails has had client-side opinions basically forever; when I started using Rails during the 2.x days in like, 2009, there were helpers that injected JavaScript to make forms better, Rails 3.1 included the asset pipeline, an attempt to compete with webpack, in 2011. Even the current generation of these things has been around for a long time, Hotwire is four years old at this point.

[cycomachead]

I mean, I think the problem with SPA-like client-side approaches are that there aren't any that have felt _good_ with Rails, let alone great.

Absolutely true that not every app needs to be a SPA from day one, but I do with there were a few more common solutions for "hybrid" apps, which use some pages as a SPA. That said, it's not that bad once you've got it setup. I like that Rails offers a solution like import maps, but I do also wish there were better core functionality for using some kind of package manager.

Like the redis analogy: Whether or not you need Redis, there are good defaults and very good 'third party' solutions for background jobs (or caching). You don't even need Redis is many cases, but it's easy to grow into.