A surprising number of people are still on low bandwidth connections, while it's probably not reasonable to optimize for them, it's at least worth considering that market occasionally.
Sometimes styling is added to make web app UX better. Sometimes Javascript is used so that, even if the first load takes more time, subsequent actions will use less bandwidth. Sometimes more stuff is put on the page because 95% of users want that information to also show up.
This is obvious and pedantic, but also counters half of the comments on these sorts of these stories
Compare this with mbasic.facebook.com, which is 22 requests, 107 KB, and 1.48 s. There are some small UX problems with basic HTML Facebook that I would recommend they improve on (placement of links/buttons, omnipresent header), but overall it is a much better experience for me since I feel much more in control. Same with basic HTML Gmail vs full Gmail.
My point is that it is absolutely possible to not give in to shitty bloated web trends driven by the expectation to increase popularity, while making a quality, profitable website.
Mind blown. It even has messaging that works without having to install privacy-invading Messenger. You have just improved my facebook UX by a country mile.
It also downscales all the media down, making it hard to appreciate a lot of things.
The main facebook site makes a lot of media requests to preload the things you're going to start reading immediately.
the main facebook site doesn't attempt to scale to the connection speed, which is unfortunate, but it offers a much better experience for those who have the bandwidth to pull in the pictures. Especially for the primary use case (scroll a bunch to see a bunch of people's stuff)
I wouldn't want Facebook to scale things to my bandwidth. That gives me less control over what I see because the system is making mostly arbitrary decisions for me.
I spent the holidays at my parents's, they're hooked to 1024kbps ADSL[0], so theoretical 128kB/s. Effectively it hovers between 80k and 120k which is fine…-ish: the connection will regularly jump to ~7% packet loss and 2000±1000ms ping. Downloading at 80k is one thing, downloading at 80k with 3s round-trip and 1 packet in 15 missing things get much trickier, especially when most pages have a really high number of resources.
[0] and nothing better is currently available short of cellular (they do get ok 4G, at least when the weather doesn't screw with it), though they're supposed to get fibre a year or two down the line
it's not an optimization, it's a best practice on the web. server side render and use javascript for progressive enhancement.
Although that doesn't mean to go ahead and throw in lodash + underscore + ramda + jquery + jquery extensions all on top of react/redux. Just because you're using a modern framework, doesn't mean it needs to be huge. You can build a basic app with preact and min+gz hitting a total size around 20-30kb.
Yes, that's more than server-rendered simple AMP-style html... on the flip side, you don't have to round trip for every screen either. It's also a LOT smaller than some of the behemoths out there, and even then, a lot of the time Images are the biggest hit in bandwidth.
If and only if you do the SPA right. Compare Twitter (slow to load, slow to interact with, battery-draining, issues with maintaining scroll position, and all of these get worse the farther you scroll down) to the SPA version of https://mobile.twitter.com/ (fast to load and interact with) to the static version of Mobile Twitter (even faster, no infinite scroll, works on Dillo).