Ask HN: Is it ok to use traditional server-side rendering these days?

Depends on your requirements. If you are chasing fads or just looking to learn, then you pick the "hottest" of the JS frameworks and go with that with the understanding that a new itch will be upon you in about 9 months and you will likely feel the need to scratch it. If you want your product to last through the latest fad, then continue to do server side rendering and augment it with the JS/Client-side framework of your choice.

Yes, it's OK technically, morally, and legally. The most important thing is that your project does what it sets out to do.

Is it OK? Who cares? As long as you solve the problem for your customer, it doesn't matter that much.

That said, I find server-side rendering to be more difficult when faced with the problem of creating the type of UI that people want these days. Generally I like the server to just be an API that a Javascript client talks to, because unless you want no dynamic/asynchronous features you're going to have to write that anyway. Now you're maintaining two apps, which is twice as much work. Sometimes it's necessary to do that, sometimes it's not... I always aim for only writing one UI, because it's like twice as fast as writing two. But no doubt people will reply to me saying they browse with Javascript disabled to get an extra 15 minutes of battery life out of their laptop, so there's that.

There are still many use cases where server side rendering makes sense.

For example, I work on a large, enterprise webapp, it has the frontend UI, which users interact with heavily: this, we have built out using clientside Javascript which interacts with the Rails backend via an API.

However, we also have an admin area -- many of those pages are used very rarely and are quite complicated. I initiated a change to build these panels using traditional server-side rendered ERB views. In the context of our codebase, it takes less code and it's easier to iterate on these without bothering with the Javascript framework.

In other cases, like my personal blog, I use Jekyll to generate a bunch of static HTML and, essentially cache all this on Github pages.

Javascript frameworks are amazing and can provide a much richer, much better experience. But, I don't necessarily think they're appropriate for all problems. One other big reason why, it just the inherent "experimental-ness" and, the churn / quick obsolescence you may find in this area. Some problems don't need to be re-solved every year or two. :)

I use entirely server-side rendering, with a slight bit of jQuery sprinkled in for the very small amount of dynamic interaction that isn't easily done via the traditional HTTP request model, like menus or popups.

Of course it's okay. Server-side rendering is still the most robust, accessible, SEO-friendly way of building websites and web applications and that's unlikely to change.

Why wouldn't it be? The only people that genuinely care what technology or programming language is used are other developers. And even then, only in certain situations.

So unless you're making a community/social network for developers and the picky type are somehow your primary audience, it doesn't matter what you pick to code your site in or how its rendered.

The average Joe doesn't care whether it's something purely server side (like old school Perl) or React.

If it works well for what you are building.

Client-side rendering and the usage of JS MV* frameworks has made great inroads and is replacing the combination of 'server-side MVC framework plus rich AJAX on the client', because in the latter scheme you have two separate parts in foreign languages held together by thin glue, and can only do limited code and transfer of expertise.

That being said, server-side rendering will continue to be a great fit for cases where you ingest data and produce a deterministic, non-interactive (or not-too-interactive) result.

Remember, the issue is that in AJAX you'd receive some async result from the server and would have to splice it into the DOM, so you're throwing these contextless snippets of data on the wire and relying on your client-side JS to do the right thing; all the while you have an entire different server-side application spitting out complete well-formed HTML documents.

In a modern, virtual-domming JS MV* framework, these two functions become the same, and you don't have to architect two different solutions.

One thing I haven't understood about JavaScript frameworks is how people go about setting meta tags for Facebook and Twitter sharing. These meta tags aren't readable by the Facebook scraper when set in JavaScript, so at least for my work, even if I do use some JavaScript framework, I also have to do some server side rendering so brands can share what they pay to share.

Maybe some people just don't care about this, and pure JavaScript works for them.

Yes, it's still ok. SPA (single page apps) should only be edge cases where you really want your website to feel like an app (see gmail as a good example).

You don't need client-side stuff until you do. If all you're doing is simple html form submissions, it doesn't make sense to integrate something like React.

But then you need validations, and server-side checks for availability, then dynamic forms based on previous input choices, and data synching to preview the profile on the right, and then - might as well use React or similar instead of jQuery with DOM manipulation.

I use server side rendering sprinkled with some JS. Works great and my users are thanking me for the simple UI.

Amazon still does. Every freaking filter checkbox you click reloads the whole page (although not sure about the header) and then loads stuff with Javascript afterwards as well.

I strongly advocate actually using SSR. Way quicker to build.

I have a strong preference for a fast and low latency server-focused application compared to pretty much anything. It just feels more solid, and I am confident that I'm less likely to run into bugs than I would on a thick client. Let browsers focus on what they excel at, parsing and rendering documents, and let the server handle business logic. Which it has to anyway: the question is whether the client also has to.

That said, this is not the direction the industry is moving in. Sadly.

I am giving a talk on this in January internally:

Make SSR Great Again - "Swinging the pendulum back to server-side rendering"

https://www.evernote.com/shard/s17/sh/08a3fdd5-7ff7-40ea-b2d...

Twitter did full client-side rendering and moved back to partial server-side rendering to reduce perceived latency. Pushing business logic to the client has a cost attached.

Personally, I would default to server side rendering unless there's a very good reason to be rendering on the client instead (and there often is).

What is "traditional server side rending"?

Server side rendering still beats js frameworks if your site depends on search engines for your traffic. I try to stick as much to server side rendering with only the required js files with minimal dependencies. It has worked wonders for my site.

Ummm... The page you are looking at is server-side rendered.

There is some movement to support universal JavaScript apps, i.e. render first hit with the server and serve the same JS code for the client to just fetch data for any page navigation after - both Angular and React support this.

That said, use whatever solves your needs/requirements/etc. in a timely fashion. Literally nothing else matters.

I know this is a joke post, but there's some happy middle ground that's possible too, without going full SPA.

If you render your pages and snippets on the server, a small amount of JS on the client can hotswap content. In the extreme of this idea, you get turbolinks from Rails where no real pageloads happen, but pages are rendered on the server.

But in the small, it can let you do a sprinkling of async calls where they make the most sense, and still keep all rendering of responses on the server.

Thoughtbot wrote about it recently:

https://robots.thoughtbot.com/how-we-replaced-react-with-pho...

Use "universal" React to only write the frontend code once. The server renders the React app to HTML, and the client attaches the click handlers and other behavior.

Here's a good example: https://github.com/erikras/react-redux-universal-hot-example

> Is it discouraged to use server-side rendering?

No, it's not! But it's discouraged to use it as the only rendering layer.

Server side rendering has its unbeatable advantages - speed. That's why you can view content on https://huu.la within second, similar methods are used by Google, Twitter, etc. A lot of people might say, we have faster networks now. Believe me, even at Bay Area, it takes time to, first, download your powerful client-side library, second, bootstrap your powerful client-side app, and third, call XHRs to fetch your data. Not to mention there are so many mobiles, with even less capable networks.

So from my experience developing Huula, I would recommend using a combined approach. For places where speed is critical, for example your landing page, help page, use server side rendering; for places where a lot of user interactions will happen, use client-side rendering since it gives your more support for componentization if that's a word and user interactions.