Hacker News new | ask | show | jobs
by there_the_and 2141 days ago
> if we're talking about building an SPA you're typically going to be building a worse solution if you can't SSR your client views, which you need a js backend to do.

I have not used React with Rails and maybe I'm misunderstanding your comment, but the react-rails readme includes a section about SSR via ExecJS and integrated with Rails:

https://github.com/reactjs/react-rails#server-side-rendering
1 comments
root_axis 2141 days ago
ExecJS functions as a JS backend in this case, its just a ruby interface for node/rhino/v8 that's a little bit clunkier to utilize.
link
there_the_and 2141 days ago
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.
link
root_axis 2141 days ago
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.
link
there_the_and 2141 days ago
> 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...

link
root_axis 2141 days ago
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).
link