Hacker News Reader

Comment by jnmandal | Hacker News Reader

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.

View on HN

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

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

Reply on news.ycombinator.com