Not to mention, the combined approach is 100% necessary if you are going to require a server render for your react||vue|ember stuff.
That is not true, you just call what you need from the JS framework and you can still use the old HAML in the other areas.
Why’s that?
We as developers already offload certain tasks to separate servers. Do you use your app server to terminate TLS connections? You could; but why would you when Nginx can do a much better job of it?
You could store you application data like usernames and password in a JSON file if you really wanted to. But why would you when you can run an SQL server and use a real database?
Pick the best tool for each job. JS frameworks handle the view layer better than Rails does.
Faster? I don't see how putting an entire app server layer in between your HTTP requests is going to make anything faster.
More maintainable? You now have an entire codebase duplicating the request your client is making. It actually breaks SRP more than it helps, because you'll need to constantly keep it in sync with your rendering/client codebase in order to perform server rendering. The individual codebases may be more maintainable but your application as a whole now has fragmented responsibilities.
I can't imagine when the trade-off of introducing an entire new layer of infrastructure into your app in addition to your normal app servers would be worth it just for the purpose of server side rendering outside of some specific niche scenario. That sounds like overengineering to the extreme.
This is factually wrong. You have a small component that mounts your front-end like a pure function. No loss in maintainability, no "duplicate" anything.
That's two different places that logic must be deployed to and tested against. It's irrelevant that it's the same render code.
The only time I can justify SPA is if you’re primarily differentiating via the UX.
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.
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.
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.
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.
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.
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.
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
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.