Hacker News Reader

Comment by robertoandred | Hacker News Reader

So you're adding Bootstrap and jQuery and Popper onto Rails, just to get a modal. What happens when that modal performs an action? If it mutates data, does it require a full page refresh to do so, causing the user to lose their context? Or does it do so without a refresh, but does that mean you've now got multiple frontend and backend ways of saving and loading data in the app? How do you maintain data consistency on the rest of the page after the mutation?

View on HN

For many cases I think you can refresh the page. The context (the same page) is mostly still there. I think it really depends on what the user is expecting to do next. For example if the modal was “are you sure you want to delete this record” a full refresh and the record appearing deleted might be a fine experience.

It's not a fine experience if the user had scrolled down the page, or had filtered down the table listing, or had set up the UI by opening a panel or whatnot.

Yes if the user must retain their state after the modal closes a full page refresh would not be the right thing. I probably wouldn’t build Figma in Rails, but I probably would build a CRM in Rails.

Hotwire introduced turbo frames and streams, removing the need for the page refresh when data is mutated

Sounds like a lot of extra functionality you have to learn, add, and use that still requires the user to wait for the backend to render a template.

There’s no waiting for the user. It’s an SPA experience without the headaches of client side state management.

I suppose what you have to learn and add is relative to what you already know and have, isn’t it?

What headaches? You mark a query as stale and it fetches new data from the backend and rerenders elements as needed automatically.

What reason is there to learn Ruby and Rails and Hotwire and streams and turbo frames and whatever the next churn is just to avoid rendering some html with javascript?

That’s rich, I bet there’s 3 new JS frameworks that came out just today lol.

You know you're not required to understand and use every piece of tech ever made, right? Who cares if someone published a hobby project?

No one is suggesting the industry immediately adopt some random new library, except for Rails fans who constantly demand everyone abandon a de facto standard like React and use their new toy.

You can post data to API endpoints with vanilla JS fairly easily now. There are a lot of simplifying cases where there's no complexity to state management - like when the data flow is one-way.

Simply posting data isn't an issue. It's just as easy to do that in a 100% client-side JS app.

The problem is what happens next. Do you reload the entire page each time the user makes any kind of change?

If your input is just a text box, you can post it whenever it is submitted and put up some kind of status gleaned from the server's response body. In another comment, I point out how easy it is for requirements to end up forcing you out of the stateless happy path of frameworkless frontend, but that doesn't mean there aren't a lot of cases where you can stay in it.

Reply on news.ycombinator.com