I suppose I’m trying to say that the default Rails/Basecamp method for page updates has not required a fundamental shift in mindset. For example:
// rjs (2006)
page[:cart].replace_html :partial => "cart"
is not radically different from:
// js.erb
$('#cart').replaceWith(<%= render :partial => "cart" %>)
The principles are the same: you’re still sending server-rendered HTML over-the-wire.
When API mode was introduced, the default approach didn’t switch to client-rendering.
I agree that the lack of full support for remote form handling is a WTF (particularly given that form_with generates a remote form by default).
Whilst there are planned changes to updating pages, which will affect rails-ujs, that doesn’t invalidate the js.erb approach for now; and if I were to create a new Rails app now, I would try not let the anticipation of something new distract me from being productive with the current tools (I get that this isn’t easy!). I can still markup templates as I’ve always done; I can speed up page loads with Turbolinks; I can organise my behaviours with Stimulus; and I can add a few sprinkles with js.erb responses. Most of that probably won’t change.
I’ve been privileged in that I’ve not had to steer colleagues away from client-rendered alternatives. Transparency over upcoming developments would be nice though (indeed I’ve kept a few Turbolinks PRs up-to-date over the years, wondering if it’s worth it), but I’m trying to offer guidance to those new to Rails development right now—you can still be very productive with the current toolkit.