Earlier quoted context omitted.
Wireguard?
Haha yes, thanks. I used Wireshark extensively the past days to debug a weird http/2 issue so I guess that messed me up a bit ;)
I do that too looking stuff up.
Engineering for Slow Internet
201–210 of 406 posts
Re: Engineering for Slow Internet
#202Earlier quoted context omitted.
Those I recognize (from interface, branding, strings, etc.): * Slack -- https://brr.fyi/media/engineering-for-slow-internet/load-err... * Signal (main screen) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * 1Password (config/about page) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * Zoom (updater screen on Mac) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d.…
Yes - name and shame. Slack is INFURIATING on intermittent connectivity. That is simply not good enough for a product who's primary value is communication. Anyone who has tried to use Slack: - in the countryside with patchy connection - abroad - in China - on the London Underground Can attest to how poor and buggy Slack is on bad internet. These aren't weird edgecases - London is a major tech hub. Remote workers and…
Slack additionally decides to hard-reload itself, seemingly without reason.
I work on the road (from a train / parking lot / etc) for five or six hours per week. My T-Mobile plan is grandfathered in, so I can't "upgrade" to a plan that allows full-speed tethering without considerably impacting my monthly bill.
Realistically, I hit around 1.5Mbps down. When Slack reloads itself, I have to stop _everything else_ that I'm doing, immediately, and give Slack full usage of my available bandwidth. Often times, it means taking my phone out of my pocket, and holding it up near the ceiling of the train, which (I've confirmed in Wireshark) reduces my packet loss. Even then, it takes two or three tries just to get Slack to load.
Re: Engineering for Slow Internet
#203It's funny how similar the problems that affect a workstation in Antartica are to designing a robust mobile app.
I personally think all apps benefit from being less reliant on a stable internet connection and that's why there's a growing local-first movement and why I'm working on Triplit[1].
[1] www.triplit.dev
Re: Engineering for Slow Internet
#204IMO author shouldn't have censored the app names. The world deserves to know.
Those I recognize (from interface, branding, strings, etc.): * Slack -- https://brr.fyi/media/engineering-for-slow-internet/load-err... * Signal (main screen) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * 1Password (config/about page) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d... * Zoom (updater screen on Mac) -- https://brr.fyi/media/engineering-for-slow-internet/in-app-d.…
I've also found that the AWS and Azure consoles behave this way. While not listed in the blog post, they load JavaScript bundles in the tens of megabytes, and must have a hard-coded timeout that fails the entire load if that JavaScript hasn't been downloaded inside of a few minutes.
To Amazon's credit, my ability to load the AWS console has improved considerably in recent months, but I can't say the same for Azure.
Re: Engineering for Slow Internet
#205Earlier quoted context omitted.
I hear you on frontend-only react. But hopefully the newer React Server Components are helping? They just send HTML over the wire (right?)
The problem isn't in what is being sent over the wire - it's in the request lifecycle. When it comes to static HTML, the browser will just slowly grind along, showing the user what it is doing. It'll incrementally render the response as it comes in. Can't download CSS or images? No big deal, you can still read text. Timeouts? Not a thing. Even if your Javascript framework is rendering HTML chunks on the server, it's…
Yep. I’m a JS dev who gets offended when people complain about JS-sites being slower because there’s zero technical reason why interactions should be slower. I honestly suspect a large part of it is that people don’t expect clicking a button to take 300ms and so they feel like the website must be poorly programmed. Whereas if they click a link and it takes 300ms to load a new version of the page they have no ill-will towards the developer because they’re used to 300ms page loads. Both interactions take 300ms but one uses the browser’s native loading UI and the other uses the webpage’s custom loading UI, making the webpage feel slow.
This isn’t to exonerate SPAs, but I don’t think it helps to talk about it as a “JavaScript” problem because it’s really a user experience problem.
Re: Engineering for Slow Internet
#206Having a lot of experience commuting on underground public transport (intermittent, congested), and living/working in Australia (remote), I can safely say that most services are terrible for people without "ideal" network conditions. On the London Underground it's particularly noticeable that most apps are terrible at handling network that comes and goes every ~2 minutes (between stops), and which takes ~15s to conne…
The London Underground not having any connectivity for decades after other metro systems showed only that high connectivity during a commute isn't necessary.
Re: Engineering for Slow Internet
#207Earlier quoted context omitted.
Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols. Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...
The generalisation of this concept is what I like call the "kilobyte" rule. A typical web page of text on a screen is about a kilobyte. Sure, you can pack more in with fine print, and obviously additional data is required to represent the styling, but the actual text is about 1 kb. If you've sent 20 MB, then that is 20,000x more data than what was displayed on the screen. Worse still, an uncompressed 4K still image i…
If your server renders the image as text we'll be right back down towards a kilobyte again. See https://www.brow.sh/
Re: Engineering for Slow Internet
#208Those of us working on apps, websites, etc, need to remember that there are lots of people out there that are not connected to the fast Wi-Fi or fibre connections we have.
Here in the UK, some networks started shutting down 3G. Some have 2G as a low energy fall back, but we're supposed to use 4G/5G now. The problem is that 4G is not available everywhere yet, some areas until recently only had good 3G signal. So I've been dropping to 2G/EDGE more often than I'd like and a lot of stuff just stops working. A lot of apps are just not tested on slow, high latency, high package loss scenarios.
Re: Engineering for Slow Internet
#209Earlier quoted context omitted.
Also wonder how many savings are still possible with a more efficient HTML/CSS/JS binary representation. Text is low tech and all but it still hurts to waste so many octets for such a relatively low amount of possible symbols. Applies to all formal languages actually. 2^(8x20x10^6) ~= 2x10^48164799 is such a ridiculously large space...
The generalisation of this concept is what I like call the "kilobyte" rule. A typical web page of text on a screen is about a kilobyte. Sure, you can pack more in with fine print, and obviously additional data is required to represent the styling, but the actual text is about 1 kb. If you've sent 20 MB, then that is 20,000x more data than what was displayed on the screen. Worse still, an uncompressed 4K still image i…
I read epubs, and they’re mostly html and css files zipped. The whole book usually comes under a MB if there’s not a lot of big pictures. Then you come across a website and for just an article you have to download tens of MBs. Disable JavaScript and the website is broken.
Re: Engineering for Slow Internet
#210Having a lot of experience commuting on underground public transport (intermittent, congested), and living/working in Australia (remote), I can safely say that most services are terrible for people without "ideal" network conditions. On the London Underground it's particularly noticeable that most apps are terrible at handling network that comes and goes every ~2 minutes (between stops), and which takes ~15s to conne…
I guess in London you get wifi only on stops, it's the same in Berlin. In Helsinki the wifi connection is available inside the trains, and in the stations. So you never get a connection loss when moving. I never understood the decision in Berlin to do this, why not just provide internet inside the train... And yeah, most of the internet works very badly when you drop the network all the time...
Yes, right now it's mostly just wifi at stations only. However, they're deploying 4G/5G coverage in the tunnels and expect 80% coverage by the end of 2024 [1].
So… you can expect apps developed by engineers in London to get much worse on slow internet in 2025. :-)