Hacker News Reader

Comment by snemvalts | Hacker News Reader

Working in a Rails based startup that took the same approach as OP, then at one point understood that we need React in the frontend, and a few years later the development process is a pain:

* Weird pockets of react everywhere (data-something-something) with tons of JSON just being interpolated into attributes.

* Webpacker and other rails magic is required for building the frontend

* Frontend and backend are tightly coupled. Default error handling is the Rails error view which certainly isn't user friendly.

* snake_case_for_data_from_ruby in frontend code

* The app feels more sluggish than if it were a SPA.

What I've learned from all this is that sometimes it's better to take the less opinionated road (SPA in this case), so you can be more specific later.

View on HN

I think there are ways to do this correctly but it has to be more static pages with JS enhancement and/or making certain sections standalone "single page apps". It sounds like you're halfway in-between and that leads to the sorts of issues you're talking about. Being halfway in-between does mean that you're also halfway to an SPA, so maybe just commit fully to that direction?

Personally, I find webpacker to be straightforward and not that magical relative to the asset pipeline.

> it's better to take the less opinionated road (SPA in this case), so you can be more specific later

Can you elaborate on this a bit? Are you saying that an SPA with React (+ other server-side pieces in NodeJS?) would have been the better choice than the Rails + some React mess you wound up with? What about sticking with just Rails, no React?

Thanks for your time.

Yeah, SPA approach would separate the frontend and backend conceptually to different microservices.

Frontend is served separately off CDNs, backend isn't involved with it. When frontend team decides on a different framework/approach, they can switch, and the frontend just consumes the backend API.

Backend focuses on building an API, doesn't have to deal with templates etc. The other server side piece doesn't necessarily have to be Node, it can be whatever the backend team wants it to be, Rails is also fine. All it has to do is spit out JSON.

I think he wanted to know why you decided that you actually needed React on the front-end, as opposed to doing it «the Rails-way»: HOTwire Stimulus etc.?

https://hotwired.dev/

Some back end devs unwilling to learn React are planning to try it.

However as I understand, it's using WebSocket. At my previous job, building a customer service view that used it solely for real time updates, I wouldn't use it for anything critical without some heavy fault tolerance (like checksums or a simple incrementable number to count how many messages have been sent). The messages can be randomly dropped by whatever is in between.

I wouldn't want to write in Stimulus as a front-end dev. It looks like writing AngularJS from 2012, way too imperative. Template and logic are also separate which makes legibility harder compared to JSX.

AFAIK Hotwire Stimulus isn’t using WebSockets. I think you’re thinking of StimulusReflex.

Normal Hotwire Stimulus is just JS controllers that references DOM nodes via CSS tags. Example: https://stimulus.hotwired.dev/

I agree that JSX is better. Check out Rux which is «A jsx-inspired way to render view components in Ruby» [to make HTML on the server]. https://github.com/camertron/rux

Reply on news.ycombinator.com