Hacker News Reader

Comment by robertoandred | Hacker News Reader

You can't build a modal with Rails.

It's not much overhead?

https://dzone.com/articles/rails-creating-modals

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?

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.

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.

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.

> You can't build a modal with Rails.

I must've dreamed up the dozens of times I did.

Unless you mean you still need JS to build the modal, which is true but I doubt GP was implying that you shouldn't use JS whatsoever. You don't need a SPA to build a modal.

SPA-like complexity sneaks up on you. You start with clear stages to user interaction that might as well be separate URLs, then you need to add more connections, then you have to add pop-out panels and things that can be open or closed in various combinations, and by the end you have manually re-implemented what most frameworks do.

If you know in advance that you will never have complicated combinations of states, then sure, go ahead and use alpine (vanilla DOM element creation makes very unreadable code) or if you won't even need to create elements don't use anything... but the situations where you really know your application won't evolve that way are very rare next to the situations where you merely don't yet know that it will.

The way I see it, rewrites are inevitable so it's best to start with what's most comfortable right now and then deal with complexity creep when the time comes. Unless the app in question is being written for BigCorp there's a decent chance that it'll never hit that level of complexity during its lifetime anyway. Starting out with an SPA feels a bit like killing a fly with a sledgehammer.

Reply on news.ycombinator.com