9 ms·

React supports server side rendering.

hu3 6y ago
and then you need a nodejs server and sacrifices of kittens to webpack gods. Everything that libs like Stimulus aim to avoid.
- davidjnelson 6y ago
  Ya depends on what you’re doing. Webpack is worth mastering though in general.
  - deleted 6y ago
    [deleted]
danjac 6y ago
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".
- davidjnelson 6y ago
  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.
  - danjac 6y ago
    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.
    - davidjnelson 6y ago
      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 https://github.com/shakacode/react_on_rails
- cercatrova 6y ago
  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.
  - Existenceblinks 6y ago
    So your system have two backends, the React backend and the api server? That does not sounds like a good investment.
    - cercatrova 6y ago
      Works fine, the NodeJS server simply builds the React page, nothing more. The API does all the heavy lifting of course.
      - davidjnelson 6y ago
        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/aurora-multi-master.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide... problem is you have to pay for each region so it's not really cost effective.
        cercatrova 6y ago
        That seems overly expensive compared to just keeping a build server
        Existenceblinks 6y ago

hu3 6y ago

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

davidjnelson 6y ago
Ya depends on what you’re doing. Webpack is worth mastering though in general.
- deleted 6y ago
  [deleted]

danjac 6y ago

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".

davidjnelson 6y ago
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.
- danjac 6y ago
  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.
  - davidjnelson 6y ago
    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 https://github.com/shakacode/react_on_rails
cercatrova 6y ago
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.
- Existenceblinks 6y ago
  So your system have two backends, the React backend and the api server? That does not sounds like a good investment.
  - cercatrova 6y ago
    Works fine, the NodeJS server simply builds the React page, nothing more. The API does all the heavy lifting of course.
    - davidjnelson 6y ago
      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/aurora-multi-master.html https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide... problem is you have to pay for each region so it's not really cost effective.
      - cercatrova 6y ago
        That seems overly expensive compared to just keeping a build server
      - Existenceblinks 6y ago