Hacker News new | ask | show | jobs
by drchopchop 682 days ago
Rails may indeed be good enough, but comparing a full-stack platform (Rails) to a frontend UX framework (React) is fundamentally unfair.
4 comments

It’s a super naive post considering rails+react is almost a standard these days.

He’s using the built in rails front end templates which React can replace trivially in a React+Rails stack and comparing React to all of the rails stack and complaining it can’t do backend which is not where React fits in.

It’s a cringeworthy post. It should not be on the front page.

Less "unfair" IMHO, and more apples-vs-oranges.

FWIW, the javascript side of Rails is historically the least settled-upon part of the framework. I'm curious how many current Rails projects use React as an alternative over the current "convention" of Turbo. Or Hotwire. Or even UJS for legacy projects.

In our current project it's Stimulus/Turbo on the admin side (maintained by the backend devs), React on the end-user side (maintained by the front-end devs). I haven't met a single front-end dev who prefers the Rails approach. Even after trying to do some light convincing and demoing. They seem to be too committed to the React ecosystem in my experience. I can respect that, too much has been built for it already, and it's generally in high demand.

Plus, Rails story has no clear JSON boundary between back and front, which creates some discomfort (i.e. learning erb) as well. As a backend dev, I'm all-in on Rails in solo projects.

I think the post is making a poorly-worded switch to talking about fragmentation in backend node packages.
Still doesn’t make sense since React isn’t a backend node package.

You can use node to bundle react into a minified js bundle. But that’s typical for any complex js usage. My raw rails apps still have a node step to bundle a bunch of js libraries I need for the front end.

I honestly think the post is just incredibly naive and they haven’t ever needed more than basic rails templated html functionality in their frontend. They can’t see the value in a larger frontend framework because they don’t need it. They tried replacing the entire rails stack with a front end and didn’t understand why anyone would use that and found it painful to do the backend stuff.

Here’s the path for the og poster to grow. Add more and more complexity to the frontend. At some point you’ll want to use the node system to manage the front end js libraries you are using. At some point you’ll want something more consistent to manage the front end across the site. You’ll look to Vue or Angular or React. You add this to your rails app and now you have a very common rails+react stack.

It can’t see a justification for this post apart from naivety.

I agree that this article is just a naive conversation trigger, and that complex front-ends will lead you down this path.

However, there's another path, which is where you keep things on the backend. Unless you're talking about very complex interactive experiences, the amount of front-end code can go from >100% of the backend code, to <5-10%. Backend always implements almost everything anyway, and the question is how much should front-end reimplement on their side too.

Every time I push for smaller front-end, I'm faced with how the team might get bored or not have enough to show on the resume.

There's no mention of React in the post...
The page was edited. It initially state how react was terrible at backend functionality and had a full paragraph on why rails was better in this aspect which was super naive.