[there_the_and]

That is obvious (it's in the name). The way your comment is phrased reads to me like you are saying that one can't use Rails and has to switch to a full JS backend for SSR. If that's not what you are saying, then it's unclear what you are actually saying and why you juxtaposed Rails / Django against a JS backend.

[root_axis]

My point is that you literally cannot SSR your client js views without a js backend, so node has a clear engineering purpose in this respect. Yes, you can import a second backend into your main backend to avoid writing node, and that's fine, maybe your team is mostly made of rubyists or maybe your existing code base is ruby, there's nothing wrong with this approach, but it is more complication and layers of abstraction than just using a js backend if you must build an SPA.

[there_the_and]

> import a second backend into your main backend

This is not typically how the term "backend" is used in this context. Most mature apps will use a variety of tools and services built in a variety of languages, but this is not referred to as "importing a second backend." In fact, your comment is apparently the first use of the phrase "import a second backend" on the entire internet: https://www.google.com/search?q=%22import+a+second+backend%2...

[root_axis]

I'm speaking metaphorically. When I say "import a second backend" I'm saying that the thing being imported into the ruby backend is literally a wrapper around the exact same runtime that is typically used to run js backends, the corollary being that the "ruby" part is unnecessary added complexity from an engineering perspective unless you have some other compelling reason to use ruby (which is certainly possible).