As I travel a ton, I can confidently tell you, that this is still not true at all, and I’m kinda disappointed that the general rule of optimizing for bad reception died.
One problem I've found in my current house is that the connection becomes flakier in heavy rain, presumably due to poor connections between the cabinet and houses. I live in Cardiff which for those unaware is one of Britain's rainiest cities. Fun times.
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.
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.
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.
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.
Another point is, subjectively, added privacy compared to say South Korean products is mostly a myth. It 100% doesn't apply if you are not US citizen and even then, fingers crossed all 3-letter agencies and device creator are not over-analyzing every single data point about you continuously, is naive. What may be better is devices are harder to steal & take ownership, but for that I would need to see some serious independent comparison, not some paid PR from which HN is not completely immune to.
Space.
You don't want to wait 3-22 minutes for a ping from Mars.
There are FOSS alternatives for about everything for hobbyist and consumer use.
Making software that is polished and reliable and automatic enough that non computer people can use it is a lot harder than just making software. I’d say it’s usually many times harder.
If computers came with Debian, Firefox and Libre Office preinstalled instead of only W11, Edge and with some Office 365 trail, the relative difficulty would be gone I think.
Same thing with most IT departments only dealing with Windows in professional settings. If you even are allowed to use something different you are on your own.
This is such a HN comment illustrating how little your average HN knows of the world beyond their tech bubble. Internet everywhere, you might have something of a point. But "high speed internet access everywhere" sounds like "I haven't travelled much in my life".