I’m an old-timer who had my mind completely blown by ROR about 20 years ago when it was still in beta. Read the first edition Dave Thomas book cover to cover. Twice. It was a revelation. Went through a Python phase for a bit, then for the past 10+ years, I’ve been in SPA-land with things like SvelteKit. Now that Rails has Hotwire (and because I’m generally interested in going back to a simpler hypermedia-based approach to web dev), I’m thinking of coming back home to Rails.
Going through my first tutorial, I’m shocked to see that changes saved to my code aren’t immediately reflected in the browser and require me to refresh manually after each change. I haven’t experienced this in literally more than 10 years. For a framework that pioneered the idea of prioritizing dev experience above all else, this doesn’t fit. So I’m not trolling, I’m genuinely curious. How do we explain this? What’s the argument against baking hot-reload into the dev server? Or am I just totally wrong and there is actually a way to enable this behavior?
Yeah, I saw that there are 3rd-party solutions to this but I still think it’s very strange that this very basic, standard dev enhancement isn’t baked in – and I bet a lot of other Rails-curious devs coming from any SPA framework (all of which have live-reload running by default) feel the same way. This is the sort of oversight that I think could be preventing more widespread adoption of Rails in 2024. It’s not a deal-breaker for me. But it’s just weird.
Admittedly not baked in to the main dev setup (yet), but take a look at Hotwire Turbo Streams. Live refresh of screens, including from the model if you wished…which would enable shared live data sessions (i.e. you and I are both simultaneously browsing the same record, you make a change, I see it updated in my browser too), or real-time updates after a queued task has updated the data, or whatever.
If you going the Hotwire way as Jez Nicholson suggested there is also the excellent/handy ‘hotwire-livereload’ gem. Which basically reloads everything.
Thanks for the recommendation – That looks great! I mean… It looks a lot like what comes standard with literally every modern JS framework. So that’s my original point. For a framework which is all about developer experience, what is the argument against including this feature as part of the standard install?
Arguments against? Performance impact and code bloat.
I’m personally neutral on this topic. But typing Ctrl-R after a code update takes just a split-second and doesn’t feel like burden to me. Nor does installing a live-reload gem.
And the general idea in Rails is that you can choose your own frameworks. Both for JS and CSS. (And a lot more via Gems.)
Leading to developer happiness and… freedom of choice.
That’s an interesting take. I was always under the impression that if you wanna roll your own, use Flask or GoLang or whatever – and Rails is for people who want all the bits included by default. Anyway… Like you said, it’s not that big of a deal to install a gem. My main point was that this kind of thing may be slowing adoption. If you’re coming from a framework like SvelteKit or Nuxt or whatever, it feels like a bit of a regression. Might be good for overall adoption to provide the same modern conveniences out of the box that other frameworks have these days.
I’m definitely a huge fan of the stability of Rails relative the absolute chaos of the shiny JS world – but… I still think that a livereload in DEV is considered more standard fare these days than a shiny new thing. Anyway… That’s my two cents.