6 ms·

Honestly, as a Rails dev, this just seems more complicated than creating a Rails app in API mode and using #{React||Vue||Ember}} for the front-end. It's extrem

Honestly, as a Rails dev, this just seems more complicated than creating a Rails app in API mode and using #{React||Vue||Ember}} for the front-end. It's extremely easy to get started with a front-end app using vue-cli. This article spends a lot of time changing Rails' default functionality to achieve behavior similar to what vue-cli gives you by typing `vue init webpack` and answering a few questions. I understand that getting up to speed with a front-end framework takes time, but in my case, it was time well-spent (I used Maximilian Schwarzmüller's Vue.js course on Udemy). There's no shame in just using Rails for the API.

joshwcomeau 9y ago
Yeah, really good point; this article is kinda halfway between "modern client-side app" and "traditional server-controlled app", and it kinda feels like the worst of both worlds (added complexity without many of the benefits)
- bpicolo 9y ago
  For what it's worth, there are a lot of good reasons to have access to both (though not saying the article is doing it the best way). There are all sorts of pages that aren't worth the boilerplate and extra time to develop (data-heavy admin pages, trivial about pages, etc). I love SPAs for the heavy-hitting User-facing pages, but for a lot of things they're total overkill and not worth the extra maintenance and development effort
vemv 9y ago
Agree in principle, but any technique is frigthening at first. Clearly for the authors this is a usual workflow - they're productive with it, and they only had to pay the complexity cost once (when figuring out things). Once you get an integrated frontend-backend system and codebase, you start to get unique benefits: - Server-rendered data, for avoiding superfluous ajax requests - Simpler deployments (fewer moving pieces) - Single codebase, less knowledge segregation and so on.
- jtmarmon 9y ago
  To your first point, you can still server side render if you use an API by serving your frontend through a server that fetches data from the API before rendering
  - hamandcheese 9y ago
    And at that point is the added complexity worth not just rendering with rails?
    - Can_Not 9y ago
      Some would say "keeping rails" or "TWO templating languages" are the unnecessary added complexity.
    - nawgszy 9y ago
      >And at that point is the added complexity worth not just ~rendering with rails~ using Node.js for your server?
- laverick 9y ago
  I'm in the middle of converting a small production Rails API + Ember app to Rails Views + Vue.js using webpacker and a lot of the techniques discussed. It's certainly been a learning curve, but I'm definitely happier with the new setup for all of the reasons you mentioned. It's not a one-size-fits-all solution, but for a single dev / small team working on a web-only application it can make a lot of sense. For anyone interested, Gorails has a series on Vue + Rails that's been very helpful. https://gorails.com/series/using-vuejs-with-rails https://gorails.com/series/using-vuejs-with-rails
jnmandal 9y ago
The downside there is that you're then forced to build your application as a completely separate service and static site. With this approach, you can stick single page app where the UI needs to be more stateful and then use traditional server-templating for other things. I'm doing this w/ phoenix now and its nice because my typeahead search is done as a JS component, but the corresponding index and show pages are still mostly the same as what was scaffolded. Not to mention, the combined approach is 100% necessary if you are going to require a server render for your react||vue|ember stuff.
- scottmf 9y ago
  >Not to mention, the combined approach is 100% necessary if you are going to require a server render for your react||vue|ember stuff Why’s that?
  - debaserab2 9y ago
    If your react/vue codebase is isolated to client end, how is your server going to render react/vue code?
    - kbutler 9y ago
      For server-side rendering see next.js for react and nuxt.js for vue.
      - nihonde 9y ago
        And fastboot for Ember.
      - jensvdh 9y ago
        Hypernova is pretty awesome for React as well!
    - Can_Not 9y ago
      You have a simple nodejs server that renders using react nextjs, vue nuxtjs, angular universal, or ember fastboot while using rails for your APIs.
deleted 9y ago
[deleted]
pmontra 9y ago
It's probably a matter of tastes, either one project or two projects. I've been working with Rails since 2006 and I'll create two separate projects. A Rails API project and a front end one. Two projects, two repositories, maybe two teams (specialized teams are more common than full stack.) The front end is served by the reverse proxy in front of Rails. If I want to serve some semi-static HTML page from Rails, all I have to do is sharing the CSS file and create a controller for that (PagesController is a classic.) I don't think there are many chances of sharing HTML in a meaningful way among ERB and JSX, that must be duplicated. Then Rails people will work with Rails tools and JavaScript people will work with the favorite tools of the month. The advantage is that if you want to onboard some pure front end developers they won't have to learn about Rails.
- demiazz 9y ago
  Of course! If you have human resource to separate and maintain backend and frontend - it's an excellent solution. But it's article not for teams like this. The described solution for full-stack developers and small projects, which needs to be maintainable too. And component manner is a proper way to organize frontend code.
  - pmontra 9y ago
    I would split in two even if I'm working on it alone.
    - demiazz 9y ago
      Ok. Let's see from another side on this point. If you are beginner Rails developer who doesn't know how to configure Webpack properly and doesn't know how to works with React/Vue/Ember? And if your project must be a SEO-friendly? You don't know React, Webpack and doesn't know how to works with React/Vue SSR. Maybe learning its tools will be an excellent investment if you want to be a front-end developer. But what if not? We wrote this article mainly for beginners full stack developers. They are not well-experienced front-end developers.

joshwcomeau 9y ago

Yeah, really good point; this article is kinda halfway between "modern client-side app" and "traditional server-controlled app", and it kinda feels like the worst of both worlds (added complexity without many of the benefits)

bpicolo 9y ago
For what it's worth, there are a lot of good reasons to have access to both (though not saying the article is doing it the best way). There are all sorts of pages that aren't worth the boilerplate and extra time to develop (data-heavy admin pages, trivial about pages, etc). I love SPAs for the heavy-hitting User-facing pages, but for a lot of things they're total overkill and not worth the extra maintenance and development effort

vemv 9y ago

Agree in principle, but any technique is frigthening at first. Clearly for the authors this is a usual workflow - they're productive with it, and they only had to pay the complexity cost once (when figuring out things). Once you get an integrated frontend-backend system and codebase, you start to get unique benefits: - Server-rendered data, for avoiding superfluous ajax requests - Simpler deployments (fewer moving pieces) - Single codebase, less knowledge segregation and so on.

jtmarmon 9y ago
To your first point, you can still server side render if you use an API by serving your frontend through a server that fetches data from the API before rendering
- hamandcheese 9y ago
  And at that point is the added complexity worth not just rendering with rails?
  - Can_Not 9y ago
    Some would say "keeping rails" or "TWO templating languages" are the unnecessary added complexity.
  - nawgszy 9y ago
    >And at that point is the added complexity worth not just ~rendering with rails~ using Node.js for your server?
laverick 9y ago
I'm in the middle of converting a small production Rails API + Ember app to Rails Views + Vue.js using webpacker and a lot of the techniques discussed. It's certainly been a learning curve, but I'm definitely happier with the new setup for all of the reasons you mentioned. It's not a one-size-fits-all solution, but for a single dev / small team working on a web-only application it can make a lot of sense. For anyone interested, Gorails has a series on Vue + Rails that's been very helpful. https://gorails.com/series/using-vuejs-with-rails https://gorails.com/series/using-vuejs-with-rails

jnmandal 9y ago

The downside there is that you're then forced to build your application as a completely separate service and static site. With this approach, you can stick single page app where the UI needs to be more stateful and then use traditional server-templating for other things. I'm doing this w/ phoenix now and its nice because my typeahead search is done as a JS component, but the corresponding index and show pages are still mostly the same as what was scaffolded. Not to mention, the combined approach is 100% necessary if you are going to require a server render for your react||vue|ember stuff.

scottmf 9y ago
>Not to mention, the combined approach is 100% necessary if you are going to require a server render for your react||vue|ember stuff Why’s that?
- debaserab2 9y ago
  If your react/vue codebase is isolated to client end, how is your server going to render react/vue code?
  - kbutler 9y ago
    For server-side rendering see next.js for react and nuxt.js for vue.
    - nihonde 9y ago
      And fastboot for Ember.
    - jensvdh 9y ago
      Hypernova is pretty awesome for React as well!
  - Can_Not 9y ago
    You have a simple nodejs server that renders using react nextjs, vue nuxtjs, angular universal, or ember fastboot while using rails for your APIs.

deleted 9y ago

[deleted]

pmontra 9y ago

It's probably a matter of tastes, either one project or two projects. I've been working with Rails since 2006 and I'll create two separate projects. A Rails API project and a front end one. Two projects, two repositories, maybe two teams (specialized teams are more common than full stack.) The front end is served by the reverse proxy in front of Rails. If I want to serve some semi-static HTML page from Rails, all I have to do is sharing the CSS file and create a controller for that (PagesController is a classic.) I don't think there are many chances of sharing HTML in a meaningful way among ERB and JSX, that must be duplicated. Then Rails people will work with Rails tools and JavaScript people will work with the favorite tools of the month. The advantage is that if you want to onboard some pure front end developers they won't have to learn about Rails.

demiazz 9y ago
Of course! If you have human resource to separate and maintain backend and frontend - it's an excellent solution. But it's article not for teams like this. The described solution for full-stack developers and small projects, which needs to be maintainable too. And component manner is a proper way to organize frontend code.
- pmontra 9y ago
  I would split in two even if I'm working on it alone.
  - demiazz 9y ago
    Ok. Let's see from another side on this point. If you are beginner Rails developer who doesn't know how to configure Webpack properly and doesn't know how to works with React/Vue/Ember? And if your project must be a SEO-friendly? You don't know React, Webpack and doesn't know how to works with React/Vue SSR. Maybe learning its tools will be an excellent investment if you want to be a front-end developer. But what if not? We wrote this article mainly for beginners full stack developers. They are not well-experienced front-end developers.