> the general rule of optimizing for bad reception died.

Yep, and people will look at you like you have two heads when you suggest that perhaps we should take this into account, because it adds both cost and complexity.

But I am sick to the gills of using software - be that on my laptop or my phone - that craps out constantly when I'm on the train, or in one of the many mobile reception black spots in the areas where I live and work, or because my rural broadband has decided to temporarily give up, because the software wasn't built with unreliable connections in mind.

It's not that bleeding difficult to build an app that stores state locally and can sync with a remote service when connectivity is restored, but companies don't want to make the effort because it's perceived to be a niche issue that only affects a small number of people a small proportion of the time and therefore not worth the extra effort and complexity.

Whereas I'd argue that it affects a decent proportion of people on at least a semi-regular basis so is probably worth the investment.

▲

asa400 2 days ago | parent | next [-]

We ignore the fallacies of distributed computing at our peril: https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

▲

visarga 2 days ago | parent | prev | next [-]

It's always a small crisis what app/book to install on my phone to give me 5-8 hours of reading while on a plane. I found one - Newsify, combine it with YT caching.

▲

donkeybeer 2 days ago | parent | prev | next [-]

Usually it reduces not adds complexity. Simpler pages without hundred different js frameworks are faster.

▲

LogicFailsMe 2 days ago | parent | prev [-]

Moving services to the cloud unfortunately relieves a lot of the complexity of software development with respect to the menagerie of possible hardware environments.

it of course leads to a crappy user experience if they don't optimize for low bandwidth, but they don't seem to care about that, have you ever checked out how useless your algorithmic Facebook feed is now? Tons of bandwidth, very little information.

It seems like their measure is time on their website equals money in their pocket and baffling you with BS is a great way to achieve that until you never visit again in disgust and frustration.

▲

wtallis 2 days ago | parent [-]

I don't think the "menagerie of possible hardware environments" excuse holds much water these days. Even web apps still need to accommodate various screen sizes and resolutions and touch vs mouse input.

Native apps need to deal with the variety in software environments (not to say that web apps are entirely insulated from this), across several mobile and desktop operating systems. In the face of that complexity, having to compile for both x86-64 and arm64 is at most a minor nuisance.

	▲	bartread 4 hours ago \| parent \| next [-]
		I don't know that it ever held that much water. I used to work for a company building desktop tools that were distributed to, depending on the tool, on the low end tens of thousands of users, and on the high end, hundreds of thousands. We had one tool that was nominally used by about a million people but, in actuality, the real number of active users each month was more like 300k. I was at the company for 10 years and I can only remember one issue where we could not reproduce or figure it out on tools that I worked on. There may have been others for other tools/teams, but the number would have been tiny because these things always got talked about. In my case the guy with the issue - who'd been super-frustrated by it for a year or more - came up to our stand when we were at a conference in the US, introduced himself, and showed me the problem he was having. He then lent me his laptop overnight[0], and I ended up installing Wireshark to see why he was experiencing massive latency on every keystroke, and what might be going on with his network shares. In the end we managed to apply a fix to our code that sidestepped the issue for users with his situation (to this day, he's been the only person - as far as I'm aware - to report this specific problem). Our tools all ran on Windows, but obviously there were multiple extent versions of both the desktop and server OS that they were run on, different versions of the .NET runtime, at the time everyone had different AV, plus whatever other applications, services, and drivers they might have running. I won't say it was a picnic - we had a support/customer success team, after all - but the vast majority of problems weren't a function of software/OS configuration. These kinds of issues did come up, and they were a pain in the ass, but except in very rare cases - as I've described here - we were always able to find a fix or workaround. Nowadays, with much better screensharing and remote control options, it would be way easier to deal with these sorts of problems than it was 15 - 20 years ago. [0] Can't imagine too many organisations being happy with that in 2025.
	▲	LogicFailsMe 2 days ago \| parent \| prev [-]
		Have you ever distributed an app on the PC to more than a million people? It might change your view. Browser issues are a different argument and I agree with you 100% there. I really wish people would pull back and hold everyone to consistent standards but they won't.