[wayneftw]

There was no mention of why server-side rendering was needed at all. Based on my companies research Google and Bing do just fine without it.

> when the server is under high load, skip the server-side render, and force the browser to perform the initial render.

With this type of contingency plan, I don't see any reason to use server-side rendering at all. We build all of our sites and apps with React and don't do it at all, for any reason at this time.

Is there something we're missing?

[simonw]

Try using client-side rendered website on a cheap Android phone on a 3G connection sometime - or even a cheap Android phone on LTE.

That's how most of the world's population will experience your site.

I'm baffled that so many sites have invested in multiple megabytes of JavaScript to render their pages. It's like our entire industry has forgotten how to build sites that can be used by anyone who's not on an LTE iPhone.

[unlinked_dll]

>That's how most of the world's population will experience your site.

Unless you're FAANG you probably don't care about most of the world's population, but the tiny slice that is most likely to see your site and generate revenue for you.

It's not baffling that most developers don't make things for most people. That's just a waste of time and money.

[izacus]

> Unless you're FAANG you probably don't care about most of the world's population, but the tiny slice that is most likely to see your site and generate revenue for you.

That is simply not true for pretty much most companies in existence. Also those users will still be mostly using phones that are significantly slower than iPhone.

> It's not baffling that most developers don't make things for most people. That's just a waste of time and money.

Empirical proof shows that most web developers make things for other web developers (optimizing for 4000$ MacBooks and 1000$ iPhones while forgetting that poor LTE signal areas exist) instead of making it for targeting your actual companies user reach.

(Remember, people who don't return on your slow loading JS bloated web site do not appear on simple dumb Google Analytics.)

[kalyantm]

What people fail to consider is even with the high end smartphones, how do we know you are guranteed full speed 4G all the time? The network speed varies greatly in various places (in the subway, through the tunnels etc) and more often that not, we have sucky network speeds even though we are on "4G"

[true_religion]

I suppose it depends on how much you want to put effort into optimizing a single app for all users, rather than having a lite version of the site.

For my company, we serve images and video. Even multi megabyte JavaScript only equals one minute of a 720p videos runtime.

For people on restricted connections, we have a lite versions with less than 100k JavaScript and videos transcoded to 260p.

[buboard]

it's not, because phone coverage can be spotty when in a car using the train, busy wifi connections etc. aren't we supposed to be optimizing for mobile? SPAs should only be used for things like gmail. Newspapers offering megabytes of javascript , when they know that a lot of their reading happens in trains is obscene.

On the one hand google promotes SPA frameworks. on the other hand , google makes AMP because they are too slow. It's not stated often enough, but modern web is schizophrenic

[Twirrim]

Facebook decided to tackle this by having traffic shaping one day a week. On that day of the week, traffic shaping means the developers get to experience the Facebook site as if they were on high latency / low bandwidth connection.

[randall]

This doesn't exist anymore. :( I just tried to see if I could opt into it, but it caused issues so we have to do it on a machine by machine basis.

[tyingq]

Not exactly the same, but there's a throttling feature in Chrome dev tools.

[Tade0]

Recently, due to a router placement issue I used up all my mobile data so my connection was slowed down to 16kbps.

Most sites/apps don't work at all at this speed with the notable exception of Hacker News and Facebook Messenger.

[Touche]

Our industry didn't forget, a generation of developers have come up who never developed web pages that way at all.

[pjmlp]

Thankfully most of our Web projects keep being SSR in Java and .NET stacks, with minimal JavaScript.

[adossi]

One of the main reasons I never bothered to learn React was that using Razor syntax in .cshtml on my ASP .NET projects has all the convenience of react with no client-side overhead. However I understand there is some benefit to delegating some of the work to clients considering the power of modern devices.

[chrshawkes]

Whether Razor or Server Side React, it's the same thing. Both are compiled and produced on the server and sent to the client. No difference except that react is a much better template engine.

[no_wizard]

You had me until that last part.

Why is React superior to Razor Templates (or for that matter, Razor pages) for server side templating?

I support the assertion that it’s a good paradigm for creating consumable SSR templates I just don’t see anything that empirically cuts it above Razor other than if you know JSX/JavaScript it’s obviously more natural but I’m assuming that’s taken for account here

[rejschaap]

React is component based, this allows for a level of encapsulation and reusability that cannot be achieved with Razor. You might not truly appreciate this until you try out React.

If you don't want to dig too deep though, compare how to add a datepicker to a view in both systems. With React it is just another component, with Razor it is a bit more finicky.

[bernawil]

On a bad connection, I'd pick a react SPA with a slow upstart over a classic server-side rendered one any day all things being equal.

With the react app there's a chance I'll have the js already cached and I'm only fetching the data. With the SSR I'll probably be fetching data and view continuously.

[irq11]

Nonsense. You haven’t experienced a slow connection recently, or you’re just loading the same sites over and over again.

People keep asserting it’s impossible to do all of the stuff we were doing on a daily basis in 2012, without the magic of megabytes of client-side code.

[bernawil]

> or you’re just loading the same sites over and over again.

That's right, I am loading the same sites again every day consuming different data. Both for work and fun. That was the whole point.

[vorpalhex]

Hopefully your site renders just fine without needing to throw servers at it. Unless you're getting into fancy webapp territory, just drop your page complexity.

[hnbreak]

> Try using client-side rendered website on a cheap Android phone...

Just not true. We test all your react sites with $100 Android phones. They render them all fine and fast.

[Twirrim]

Client side rendering sucks for anyone on high latency networks (a significant potential customer base). From an SEO perspective it leaves you subject to whenever the search engine has rendering capacity available.

There's some good write up here: https://medium.com/@benjburkholder/javascript-seo-server-sid...

Essentially content that requires client side rendering gets stuck waiting for Google to have resources available to render the content, which is likely scaled to keep the queue at what _they_ determine to be a reasonable length. That can mean a lag of up to days or weeks after the page was first touched before they have the content indexed and in SEO. Worse, search engines don't cache javascript the same way that your end users do. An end user returning to your site likely has all your javascript pre-cached ready to go. A search engine will be starting from scratch each time. That's a lot more requests hitting your server (vs server-side rendering) and so a slower page response time (which impacts SEO rank)

My first gut instinct to this hybrid SSR-CSR approach in the article was that it's nasty, but I really like the trade-off they hit. That's a really nice failure mode. Something happening on the client side is way better than nothing, even if that something is slow.

On a side note, server-side rendering is almost certainly more efficient overall. When running under a JIT environment, methods will have already been compiled down to native code. The code is likely already in memory and ready to execute so there is no parsing / compilation time involved (and you have the advantage of OS level caching, cpu caches etc on your side). The server CPU is almost certainly faster than the client's CPU and will be more likely to be in an awake state (there is measurable latency in a CPU waking from any of the sleep or lower power/frequency states). You're trading off once-per-server parse/compilation phase vs one-per-client-per-access.

[danpalmer]

As a plus to the SSR part, you’ll also likely have any API resources either already loaded out of the database, or very close in latency to the renderer, whereas on the client you could easily be 100ms of latency plus other overheads away.

[a13n]

The two main benefits of SSR are SEO and performance.

SEO: If you don't server-side render your website, your SEO will certainly suffer. Google says they execute your JS, and to some extent they do, but your ranking will be worse and fewer pages will be scraped. We experienced this first hand.

Perf: User will stare at a blank page while they wait for your JS to download and execute. On a slow connection this could be many seconds slower than SSR.

[danpalmer]

To expand on this, Google execute your JS, but in a slightly odd JS environment (I.e. randomness isn’t random, time might not be correct, etc). They give each site a CPU time budget, and your JS execution eats into this.

If you have 5 pages that take seconds to render you might be fine, if you have 100k pages that take 50ms to render you might be in trouble.

Some of the detail of this is exposed in the webmaster tools that Google provide.

[TheSpiciestDev]

I haven't seen anyone reply to you yet specifying social media and SEO.

For example, copying a route from your SPA and pasting it into Twitter, Facebook, Slack, Teams, etc. Preferably you want the copied page's title, description and icon and not just your SPA's generic info.

[Vesuvium]

I find it ironic and explicatory of the incompentency level we have reached in IT today.

Technologies used outside of their context and "developers" having to deal with complex problems they should not even have in the first place.

[mattmcknight]

Do people call returning HTML/CSS/images from a server "rendering" now? The browser still "renders" the HTML into a visible UI.

[crooked-v]

In this context, 'render' means transforming React (or similar framework) output into a DOM tree, plus the magic that goes into rehydrating dynamic elements once the static copy of the page is loaded.

The benefit of that is getting all the effects of 'just plain HTML' while still being able to dynamically update parts of the page, and doing the entire thing in a single framework such that (if you do it right) your code doesn't have to explicitly do anything to specially handle the two different use cases.

[hnbreak]

yes they call this rendering now but just in the context SSR vs SPA

[bernawil]

> With this type of contingency plan, I don't see any reason to use server-side rendering at all

A case of vital context missing. Ever tried something like Next.js? It's a react framework for client + server-side rendering. What's really cool about it is that it does SSR for the initial view and the client-side react picks it up from there. It doesn't sound very impressive like that but where it blew my mind was when I realized that I could save URLs for some deeply nested view in a react site, enter that URL later and I'd get an instantaneous SSR'd view seamlessly.

I guess what I'm trying to say is that some tech is cool like that, not really a contingency plan but a plan.

[scrumbledober]

In a previous job where we worked with extremely low margins and very un-invested users who would bounce if the load time was too low, we used react's server-side rendering without using any react in our pages just to get a faster page load.

[pmontra]

SSR was eating up the RAM of our production server like 7.5 GB for Node and 0.5 for our Elixir backend. That was insane. We decided to shutdown SSR and check if anybody would notice. Apparently they didn't. However that webapp is a service that customers use from their computers in their office, not something mobile. We expect fast connections.

[rhizome]

I'm fairly confident "SSR" itself wasn't the culprit. Maybe there was something in the way your developers were implementing the site within it, but just with pages as rendering targets? Doubtful!

[encoderer]

If you have a small website google will render your JavaScript for every crawled page. For large websites only a sample of pages are fully rendered. Your seo will suffer.

[sgslo]

SEO alone is a poor reason to use server side rendering. Services like https://prerender.io/ completely solve SEO for SPA's and can be as cheap as $0 per month. Compare that to dozens/hundreds of hours of engineering time spent setting up an SSR implementation; it is a no-brainer.

[antris]

That service is like solving a problem with duct tape. The service could at any time disappear, introduce compatibility issues etc. It is a useful stopgap for some situations, but I would never want a high-traffic site with big uptime demands relying on a black box like this.

Especially when server-side rendering is so easy nowadays if you pick the correct stack.

[nkingsy]

This advice is badly out of date. Crawlers no longer respect the fragment meta tag, so unless the pretender is actually served, this service does nothing

[platform]

Article mentions that server-side rendering was needed for SEO (Search engine optimization) and first-page load speed

(normally server-side rendering first-page loads faster because it is pre-rendered (and often cached) ).

>"... SEO was a very important consideration — we had full-time SEO consultants on staff — and we wanted to provide the best possible page load speed, so server-side rendering quickly became a requirement. ..."

[KaoruAoiShiho]

In practice google does not really work with SPAs. This is why internet research can be dangerous.

[rhizome]

>Is there something we're missing?

Yes: when the user's browser is under high load.

[hnbreak]

Thought it's known that SSR is better at SEO.

[dominotw]

what do you do with the intial "loading" screen? I would prefer if my app didn't need that.

[suff]

You are not missing anything. This is a reheated anti-pattern that was (poorly) conceived in the 90's, and managed to crawl back. Was a great way to break a monolithic app back then, and it's still a great way to break a modular, scalable, cloud based web app now.