5 ms·

You can have an SPA and still use Rails. Rails would just serve JSON instead of the HTML. Your JavaScript frontend would use that JSON to display stuff and hand

You can have an SPA and still use Rails. Rails would just serve JSON instead of the HTML. Your JavaScript frontend would use that JSON to display stuff and handle actions. Plenty of companies do this. Cannot speak about amount of junior/entry level jobs out there but in NYC Rails jobs are plentiful.

enraged_camel 10y ago
Are there any recent, up-to-date and comprehensive tutorials that show how to use React with Rails while following the conventions of both frameworks? Every tutorial I've seen focuses on either one, but I haven't found one that focuses on both.
- JohnBooty 10y ago
  There's a reason why you don't see specific Rails+React tutorials - since they're just communicating with each other other JSON, Rails doesn't need to know or care that it's React, Angular, or whatever on the other end. The reverse is true for React, it doesn't care where the data's coming from. You'd simply want to look for a Rails tutorial that focuses on building an API using Rails. It's probably slightly easier to learn React first IMHO.
  - enraged_camel 10y ago
    Yeah, I actually know both Rails and React, and have built stuff with them separately. I understand they would talk to each other using JSON and don't need to be "aware" of each other. The main thing that I find confusing is the build/deployment process of a Rails application that uses React as the front-end. For example, let's say that I develop a Rails/React app and want to deploy it. Do I run webpack first to transpile the React app to "regular" JavaScript, then git commit, then push to Heroku? Or does Heroku do that for me? Also, how does the Rails asset pipeline come into play? Any special configurations? Etc.
    - jon-wood 10y ago
      If you're going down the road of a React based SPA on top of a Rails API (and I'd question hard if you'll really benefit from that) do yourself a favour and just treat them as entirely separate applications. The backend deploys as you'll be used to with Rails, and the front-end can be built locally and then pushed to anywhere that'll serve some static HTML.
      - pault 10y ago
        ^^^ This. Unless you're building a CMS with a large and complicated administration UI, an SPA is probably overkill and will needlessly complicate your development process.
      - enraged_camel 10y ago
        Ah, gotcha. Thanks, that makes sense. >>If you're going down the road of a React based SPA on top of a Rails API (and I'd question hard if you'll really benefit from that) Why would you question it? At least my understanding is that there would be a noticeable performance benefit, since building HTML views on the server can contribute 150-300 ms to the overall responsiveness (or so I've read). I feel like React views would be a lot snappier.
        reitanqild 10y ago
        Meh. Mostly JS frontends are just for annoying grumpy oldtimers like us here at HN. Seriously: unless you have a serious good reason for depending on JS in the frontend then keep it to progressive enhancements: autocomplete etc.
        jon-wood 10y ago
        Done right yes, it will feel a bit snappier, and you can integrate offline support without a huge amount of extra complexity on top of your SPA. Sadly the trade-off currently is that your frontend is going to be far more complex to build than if you just rendered some HTML from Rails. You end up needing to duplicate your model layer in the frontend, debugging is harder because now the bugs are on the client side, which you have no access to after the fact, and integration testing becomes a very real challenge. These are all surmountable problems, but they're not trivial, and in my opinion they're not worth it for a few hundred ms of response time, especially when you can get close to the speed ups offered with some judicious use of caching, Turbolinks, and a thin layer of JavaScript in the places it makes most sense.

enraged_camel 10y ago

Are there any recent, up-to-date and comprehensive tutorials that show how to use React with Rails while following the conventions of both frameworks? Every tutorial I've seen focuses on either one, but I haven't found one that focuses on both.

JohnBooty 10y ago
There's a reason why you don't see specific Rails+React tutorials - since they're just communicating with each other other JSON, Rails doesn't need to know or care that it's React, Angular, or whatever on the other end. The reverse is true for React, it doesn't care where the data's coming from. You'd simply want to look for a Rails tutorial that focuses on building an API using Rails. It's probably slightly easier to learn React first IMHO.
- enraged_camel 10y ago
  Yeah, I actually know both Rails and React, and have built stuff with them separately. I understand they would talk to each other using JSON and don't need to be "aware" of each other. The main thing that I find confusing is the build/deployment process of a Rails application that uses React as the front-end. For example, let's say that I develop a Rails/React app and want to deploy it. Do I run webpack first to transpile the React app to "regular" JavaScript, then git commit, then push to Heroku? Or does Heroku do that for me? Also, how does the Rails asset pipeline come into play? Any special configurations? Etc.
  - jon-wood 10y ago
    If you're going down the road of a React based SPA on top of a Rails API (and I'd question hard if you'll really benefit from that) do yourself a favour and just treat them as entirely separate applications. The backend deploys as you'll be used to with Rails, and the front-end can be built locally and then pushed to anywhere that'll serve some static HTML.
    - pault 10y ago
      ^^^ This. Unless you're building a CMS with a large and complicated administration UI, an SPA is probably overkill and will needlessly complicate your development process.
    - enraged_camel 10y ago
      Ah, gotcha. Thanks, that makes sense. >>If you're going down the road of a React based SPA on top of a Rails API (and I'd question hard if you'll really benefit from that) Why would you question it? At least my understanding is that there would be a noticeable performance benefit, since building HTML views on the server can contribute 150-300 ms to the overall responsiveness (or so I've read). I feel like React views would be a lot snappier.
      - reitanqild 10y ago
        Meh. Mostly JS frontends are just for annoying grumpy oldtimers like us here at HN. Seriously: unless you have a serious good reason for depending on JS in the frontend then keep it to progressive enhancements: autocomplete etc.
      - jon-wood 10y ago
        Done right yes, it will feel a bit snappier, and you can integrate offline support without a huge amount of extra complexity on top of your SPA. Sadly the trade-off currently is that your frontend is going to be far more complex to build than if you just rendered some HTML from Rails. You end up needing to duplicate your model layer in the frontend, debugging is harder because now the bugs are on the client side, which you have no access to after the fact, and integration testing becomes a very real challenge. These are all surmountable problems, but they're not trivial, and in my opinion they're not worth it for a few hundred ms of response time, especially when you can get close to the speed ups offered with some judicious use of caching, Turbolinks, and a thin layer of JavaScript in the places it makes most sense.