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

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

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"

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.

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

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.

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.

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

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.

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

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

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.

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.

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

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.

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.

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.

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

Please don't be a jerk in comments here. I'm sure you can make your substantive points without that.

https://news.ycombinator.com/newsguidelines.html

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.

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