Rails Webpacker or Vue-CLI?
Asked Answered
K

1

9

I'm building a Single Page (Web) Application. I'm quite smitten by Rails v5.0, especially its built-in API capabilities.

In the past I've built JavaScript frontends using Vue.js, usually with the templates provided by the Vue-CLI project. This allows deployment of Vue component-based static sites basically anywhere. It's great.

Now, Rails 5.1 has some built-in Webpack and Yarn features which look pretty compelling too. I'm not sure how to proceed with my new application.

My questions:

  • What are the pros/cons of integrating Webpack and Vue into Rails itself, using the Webpacker extensions available in Rails v5.1? I intend to deploy to Heroku.
  • On the other hand, what are the pros/cons of using the Rails API-only mode for the backend, and maintaning the Vue/Webpack-based frontend in its own directory? I'd keep everything in the same repository, deploy the backend via Heroku, and the frontend via a static host like Netlify.
  • Which approach would have more cognitive overhead or technical complexity?

Over the past few days, I've been looking around, and I've not found much concise information on the web about this. People seem interested in the auto-reloading features of the Rails development environment, but I get that for free already with Vue-CLI.

As far as I can discern, these are reasons for keeping them separate:

  • Deployment of the frontend is pretty darn simple to anywhere.
  • The Webpacker mode for Rails is very new, and not many tutorials or guides exist yet, especially regarding integration testing. Keeping things separate means that my existing testing apparatus should still apply.

Here are some pros for integrating the two parts together:

  • The possibility of using static assets both for the frontend and possibly for server-generated pages in the future, should that be necessary.
  • Buy-in to "the Rails way", with implied future maintenance by the Rails team.
  • the JS Frontend would not need to be hosted separately.
  • Don't need to worry about CORS (?)

What other concrete benefits exist for either approach?

Katheryn answered 22/12, 2017 at 15:27 Comment(2)
You don't need to keep js frontend separately in case of the separate frontend because you can compile it and save it in public Rails folder. I've did this for angular + Rails, ex.: github.com/alexkojin/advicy . Frontend code generates in deploy.rb script.Thurgau
@AlexKojin yeah, I was thinking about that: kind of a middle ground. Vue-CLI compiles to a dist folder, but you can certainly point Webpack to the Rails public folder instead. I left this out of the question because I was concerned it would muddy the waters. ThanksKatheryn
A
2

When i started i went the webpacker way, somewhow because that's what it looked like it was "supposed" to be. As you say, very little guidance. Webpacker (with it's reliance on the latest node) seems a moving target, making deployment and even development more complex. For what benefit i asked and got rid of it.

Now i use vue from the cdn. Benefits:

  • cached close to user
  • almost zero installation
  • easy to have dev/production versions

The i write app code into the rails templates. Using haml, and in fact ruby2js, but you can use javascript just fine. That's how i started, but i like ruby, and the ruby code is almost half the size than the generated js, but i'm getting off track.

So templates are your "vue annoted" rails templates. Small code also goes into the rails template. More code can be defined in the assets and referred to from the app. Even components can be written into template using the x-template syntax.

And last but not least: Data can be transferred by to_json, directly into the templates. And in the same render. Much faster than an additional query. When to_json is not enough one can use rabl to get exactly what is needed.

I hope i made that clear. I am in the process of writing some vue-rails stuff up, as there is so little to be found. Look out here (and i'll comment when the post is ready)

Adalie answered 19/1, 2018 at 14:43 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.