Hacker News Reader

Comment by symfoniq | Hacker News Reader

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.

View on HN

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.

>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?

If your react/vue codebase is isolated to client end, how is your server going to render react/vue code?

For server-side rendering see next.js for react and nuxt.js for vue.

And fastboot for Ember.

Hypernova is pretty awesome for React as well!

You have a simple nodejs server that renders using react nextjs, vue nuxtjs, angular universal, or ember fastboot while using rails for your APIs.

So now you've simplified your 1 app server into 2 app servers that aren't even the same language or environment.

Thus creating cleaner, more focused, more testable, likely faster, and more maintainable code bases. Which also adhere to the Single-Responsibility Principle.

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.

More testable? Because they are discrete codebases, possibly. It sure sounds like getting a dev environment setup that mirrors the production env just got a lot harder. Given there is an entire new codebase there is now an overall larger coverage area to test.

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.

> You now have an entire codebase duplicating the request your client is making

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.

Not at all. There are two HTTP requests: one from your client to your rendering server and one from your rendering server to your app.

That's two different places that logic must be deployed to and tested against. It's irrelevant that it's the same render code.

Except all 4+ SSR and framework teams have been working on this technology for years and put a lot of thought and design into it, so it's not so randomly sloppy that the one client SPA will need duplicate testing suites just to prerender HTML serverside.

The specific contention is that the JS frameworks aren’t any/much better for user and they are unquestionably harder to develop.

The only time I can justify SPA is if you’re primarily differentiating via the UX.

That's a bit misleading. There's several tools you have available and you should pick the best tool for the job. Also, SPAs are only harder if you haven't already learned them. For anything too complex to not simply use WordPress, it's often preferable to use an SPA for the superior UI/UX experience (both for the developers and the user). Plenty of exceptions are welcome though, for example if the site's functionality is based around a key jQuery plugin.

The Nuxtjs (and the others) SSR peices are not "an entire extra app you write and maintain", it's a small component, mostly already written by the nuxt team, that does one thing. It allows you to write a leaner, better focused backend.

> The downside there is that you're then forced to build your application as a completely separate service and static site.

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.

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.

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.

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.

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.

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

And at that point is the added complexity worth not just rendering with rails?

Some would say "keeping rails" or "TWO templating languages" are the unnecessary added complexity.

>And at that point is the added complexity worth not just ~rendering with rails~ using Node.js for your server?

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

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)

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

Reply on news.ycombinator.com