Hacker News Reader

Comment by davidjnelson | Hacker News Reader

React is great though, why not just use that?

React is great if all your frontend is React. Using it to create reusable components to sprinkle in your static HTML is overkill, and anyway it does not work with LiveView and LiveView is pretty cool.

IMO React has a good data model and solid foundation, but the whole ecosystem it's relying upon is bad. I'm not a fan.

True, that’s not its use case.

because then you need an api

React supports server side rendering.

and then you need a nodejs server and sacrifices of kittens to webpack gods. Everything that libs like Stimulus aim to avoid.

Ya depends on what you’re doing. Webpack is worth mastering though in general.

Sure, but where is your data and business logic going to live? If the answer is "just write it in JS" then it's no longer a question of "just use React" but "let's replace our entire stack with Javascript".

Ya it really depends. I like redis and Postgres generally speaking for data, and Ruby on Rails generally for business logic. And you can certainly do universal rendering with that easily with react_on_rails. If you do end up needing more perf, maybe go would be interesting.

Yes but we're still going a long way from "just use React". One benefit of the "JS sprinkles" approach of Turbolinks+Stimulus is that you have a far simpler and more productive stack: Rails (or other framework) renders templates with some minimal JS on the frontend, as opposed to the inherent complexity of API + SSR + SPA. There are occasions when React is a good choice of course, but let's not underestimate the costs of the SPA architecture.

hey if stimulus and turbolinks are your jam then rock it!

I would at least give this a look though, it's super easy to use: https://github.com/shakacode/react_on_rails

Why would the entire stack be JS? Even in server side React, it can still fetch from APIs, so presumably you have a backend to fetch from, in whatever language and database you want.

So your system have two backends, the React backend and the api server? That does not sounds like a good investment.

Works fine, the NodeJS server simply builds the React page, nothing more. The API does all the heavy lifting of course.

yup, and if you want to really optimize it you could use functions as a service like lambda as your react rendering layer, which forwards to heroku or fargate or beanstalk or vanilla ec2 or whatever for your backend.

and if cloudflare workers ever support metered usage you could use that too for the react layer.

and if you want hyper performance you could use lambda@edge and intelligently route to your backend running on fly.io to minimize the distance. the somewhat unsolved problem there though is multi region master master replicated databases which are cost effective.

to my knowledge this is the current state of the art for that https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...

problem is you have to pay for each region so it's not really cost effective.

That seems overly expensive compared to just keeping a build server

I thought you were making joke about complexity when I read the first line, but then in the end it's not a joke. Why don't you have 1 single backend peacefully. JS sprinkles for what it needs to be interactive. (I'm tired of "complex form " argument, jQuery turned out ok back then, so does Stimulus or whatever works with server rendered html (e.g. vue))

This sounds like madness. Not cost effective to deploy, nor cost effective at all to implement in the first place. It's literally setting money on fire.

What's the equivalent of Poe's law, but for software development?

Reply on news.ycombinator.com