Hacker News new | ask | show | jobs
by mehwoot 3546 days ago
Even for a simple app that it'd take me 20 - 30 hours

If your entire job is doing small apps that take a week of work, these tools are not much better than the previous generation (personally I'd use Rails but that's just one generation on from PHP/MySQL). Especially when you add in the cost of non uniformity if you let everyone choose their own slightly different flavour of the innumerable javascript tools available.

But as part of a team that has migrated a 5 year old codebase from Rails to React in the last year, whilst I was skeptical at first, React has been an absolute godsend. Everything we build now is so much more modular and much closer to how non tech people view our website (and so how they ask for features), which makes it easier to develop. React isn't designed to help "I need to build this 20 hour website quicker".

I think the problem is mostly cargo culting. Smart and outspoken developers use these tools, but they're also the ones dealing with complex problems at their jobs, not everybody needs to solve the problems they are solving. And "Honestly Rails is good enough for this app" doesn't make for a very sexy meetup presentation.

3 comments

> migrated a 5 year old codebase from Rails to React

This statement doesn't make sense to me, and is one of the points of the article. React is a view layer. That's it. So you wouldn't migrate from Rails to React. You'd migrate Rails to React + Relay + Webpack + etc. On top of all of that you then have to decide if you're sticking with Rails for your API or if you're switching over your entire back end as well. The decision debt is just insane, and given how often these things change, that debt never goes away.

It makes sense to me. The previous generations had pages that had more rendering on the server and "forms." Now, it's single page applications hitting REST end points.

So before, you had complex models, tightly bound back-end controllers, sending data to a view.

Now, you have simpler APIs on the server, you arrange and manage the data in the browser, getting more data as needed.

Rails is perfectly well suited to serve an API. In fact I believe it was the first to define off the shelf RESTful conventions for an entire controller and all verbs by default back ~2007 if I recall.

http://edgeguides.rubyonrails.org/api_app.html

Actually, Rails 5 implements an API mode so you can spin up a new app with only API-level conventions that runs on less memory and just serves JSON. You can add on the standard Postgres DB and Boom! "You just made Rails great again"
Right, that's what I linked to ;)
Oh, I didn't click that... Derp!
Sorry, I'm confused: what do you mean by "migrated a 5 year old codebase from Rails to React"? What are you using as your backend?
Just one of the many ways that modern Javascript baffles me - people pretend the client and server are equivalent.
The more technical details you include the more people pick up and discuss minute technical details instead of the point of what I was trying to say, which is that my experience with a large codebase was these modern javascript tools have solved a lot of problems we had.

If you want all the gory details here they are: it was a Rails 3 app using Postgres and Elasticsearch that we migrated to React + node.js + webpack + babel, elastic search as the data store and using Keystone.js for backend data manipulation (which uses mongodb). Rails was indexing its data in Elasticsearch already so we could start serving data through node.js immediately without having to migrate all the data backend, which is being slowly moved to keystone.js.

You can still render placeholders from the server and fill these in with React
Maybe they hardcoded the data in the views. Might be the cool way to do it soon enough.
Sorry I should have clarified. React + node.js. We need the option of HTML being sent to clients so React + Rails wasn't an option
What did you you use for the backend?