I would split in two even if I'm working on it alone.

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.

Another case. My case.

My project started more than four years ago. It was a mainly content project around content creating and sharing, and of course SEO.

Facebook released React two month early than we started. Webpack has not yet created. Gulp is a bleeding edge. And we used sprockets, CoffeeScript and SASS.

It's is a massive project now. And it changed development vector for last year. We make a lot of changes, and we haven't resourced for rewriting them on separated front-end and back-end for now.

But described methodology allows us to keep this project maintainable. We migrated this approach from Sprockets to Gulp, and from Gulp to Webpack.

And we thought. What if we tell about how we maintain the project to beginners? They are writing jQuery-spaghetti code, and they may don't know frontend frameworks and Webpack.

Let's tell them how to write maintainable code with webpacker, components, BEM and our code organization. It's maybe a good starting point for them.

Did you try create_react_app? I find it way easier to setup my frontend using it than to use webpacker, even being used to both rails and react. You type "yarn build", and you have properly fingerprinted js and css files ready to use, with an `index.html` file that includes them. It's great to only focus on backend in rails, and it brings all the cool thing from js dev for free: babel, webpack, yarn, live reload, import of css files, etc.

SSR is indeed still a problem (I've build a cache system that will render pages with chrome headless, for that), but gladly, it's about to be solved (at least for the SEO part): https://webmasters.googleblog.com/2017/12/rendering-ajax-cra...

The biggest problem yet to be solved: properly handling 404 status.

We did not set a goal to teach well-experienced front-end developers how to organize their code. The well-experienced developer knows about many ways of code organization and can choose one for a project depending on the situation.