Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Engineering for Slow Internet

brr.fyi

Post reply on HN
Print view View original

111–120 of 406 posts

Re: Engineering for Slow Internet

#111

Post by swiftcoder »

cheema33 wrote: post #78
toast0 wrote: post #52

Earlier quoted context omitted.

> I bet that WhatsApp is one of the rare services you use which actually deployed servers to Australia. To me, 200ms is a telltale sign of intercontinental traffic. So, I used to work at WhatsApp. And we got this kind of praise when we only had servers in Reston, Virginia (not at aws us-east1, but in the same neighborhood). Nowadays, Facebook is most likely terminating connections in Australia, but messaging most lik…

> I used to work at WhatsApp.. Do you know why there is a 4 device limit? I run into this limit quite a bit, because I have a lot more devices. And... Why is there is WhatsApp for most commonly used devices, but iPads?

> Why is there is WhatsApp for most commonly used devices, but iPads?

I was frustrated by this a while back, so I asked the PMs. Basically when investing engineering effort WhatsApp prioritises the overall number of users connected, and supporting iPads doesn't really move that metric, because (a) the vast majority of iPad owners also own a smartphone, and (b) iPads are pretty rare outside of wealthy western cities.

Re: Engineering for Slow Internet

#112

Post by lawgimenez »

djtango wrote: post #64
future10se wrote: post #19

Earlier 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…

Telegram also works well in remote places.

Re: Engineering for Slow Internet

#113

Post by jiggawatts »

devjab wrote: post #85
padolsey wrote: post #43

A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet. Being behind the great firewall means using creative approaches. VPNs only sometimes work, and each leaves a signature that the firewall's hueristics and ML can eventually catch onto. Even state-mandated ones are 'gently' limited at times of political sensitivity. It all ends up meaning that, even if I get a connectio…

We design for slow internet, react is one of the better options for it with ssr, code splitting and http2 push, mixed in with more off-line friendly clients like Tauri. You can also deploy very near people if you work “on the edge”. I’m not necessarily disagreeing with your overall point, but modern JS is actually rather good at dealing with slow internet for server-client “applications”. It’s not necessarily easy to…

By far the lightest weight JS framework isn't React, it's no javascript at all.

I regularly talk to developers who aren't even aware that this is an option.

Re: Engineering for Slow Internet

#114

Post by crote »

kylehotchkiss wrote: post #67
padolsey wrote: post #43

A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet. Being behind the great firewall means using creative approaches. VPNs only sometimes work, and each leaves a signature that the firewall's hueristics and ML can eventually catch onto. Even state-mandated ones are 'gently' limited at times of political sensitivity. It all ends up meaning that, even if I get a connectio…

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 still essentially hijacking the entire request. You'll have some button in your app, which fires off a request when clicked. But it's now up to the individual developer to properly implement things like progress bars/spinners, timouts, retries, and all the rest the browser normally handles for you.

They never get this right. Often you're stuck with an app which will give absolutely zero feedback on user action, only updating the UI when the response has been received. Request failed? Sorry, gotta F5 that app because you're now stuck in an invalid state!

Re: Engineering for Slow Internet

#115

Post by jiggawatts »

padolsey wrote: post #54
auggierose wrote: post #53

Earlier quoted context omitted.

I guess they should fix their government, then.

What an incredibly naive and dismissive thing to say.

It isn't naive, and isn't dismissive.

The problem is the CCP.

The only fix is for the people to rise up against them.

This doesn't even have to be violent. Most of the former Soviet Block governments fell without any bloodshed.

What's the alternative? Wait for Xi to "make his mark on history" in the same way that Putin is doing in Ukraine because it's "naive and dismissive" to even talk about unseating him?

Re: Engineering for Slow Internet

#116

Post by mike_hearn »

jiggawatts wrote: post #113
devjab wrote: post #85

Earlier quoted context omitted.

We design for slow internet, react is one of the better options for it with ssr, code splitting and http2 push, mixed in with more off-line friendly clients like Tauri. You can also deploy very near people if you work “on the edge”. I’m not necessarily disagreeing with your overall point, but modern JS is actually rather good at dealing with slow internet for server-client “applications”. It’s not necessarily easy to…

By far the lightest weight JS framework isn't React, it's no javascript at all . I regularly talk to developers who aren't even aware that this is an option.

If you're behind an overloaded geosynchronous satellite then no JS at all just moves the pain around. At least once it's loaded a JS-heavy app will respond to most mouse clicks and scrolls quickly. If there's no JS then every single click will go back to the server and reload the entire page, even if all that's needed is to open a small popup or reload a single word of text.

Re: Engineering for Slow Internet

#118

Post by bayindirh »

mike_hearn wrote: post #116
jiggawatts wrote: post #113

Earlier quoted context omitted.

By far the lightest weight JS framework isn't React, it's no javascript at all . I regularly talk to developers who aren't even aware that this is an option.

If you're behind an overloaded geosynchronous satellite then no JS at all just moves the pain around. At least once it's loaded a JS-heavy app will respond to most mouse clicks and scrolls quickly. If there's no JS then every single click will go back to the server and reload the entire page, even if all that's needed is to open a small popup or reload a single word of text.

However, getting 6.4KB of data (just tested on my blog) or 60KB of data (a git.sr.ht repository with a README.md and a PNG) is way better than getting 20MB of frameworks in the first place.

Re: Engineering for Slow Internet

#119

Post by avh02 »

nicbou wrote: post #105
rkachowski wrote: post #91

Earlier quoted context omitted.

Despite Berlin's general lack of parity with modern technology, I've never actually had a problem with internet access across the ubahn network in the past decade. I noticed that certain carriers used to have very different availability when travelling and so switched to a better one, but I was always surprised at being able to handle mobile data whilst underground.

Really? I don't even get consistent internet on the Ringbahn. There are lots of holes in the coverage in Berlin. Which provider are you with? Vodafone is still dead in large parts of the U-Bahn, but I know that one of them works much better.

used to have spotty coverage underground with vodafone, when i switched to telekom, internet suddenly magically worked underground on the routes i used.

I believe someone published a map of the data coverage of different providers on the berlin ubahn, but probably outdated now

Re: Engineering for Slow Internet

#120

Post by anthk »

Mosh and NNCP will help a lot, but you need some good sysadmin to set NNCP as the mail MUA/MTA backend to spool everything efficiently. NNCP it's an expert level skill, but your data will be sent over very unreliable channels:

https://nncp.mirrors.quux.org/Use-cases.html

Also, relying on propietary OS'es is not recommended. Apple and iOS are disasters to work on remote, isolated places. No wonder no one uses Apple in Europe for any serious work except for iOS development. Most science and engineering setups will use anything else as a backend.

Most offline distros, like Ubuntu or Trisquel have methods of downloading the software packages for offline installs.

On chats, Slack and Zoom are disasters. Any SIP or Jabber client with VOIP support will be far more reliable as it can use several different protocols which can use far less bandwidth (OPUS for audio) without having to download tons of JS to use it, even if you cached your web app it will still download tons of crap in the background.

And, again, distros like Debian have a full offline DVD/BR pack which ironically can be better if you got that by mail. Or you can just use the downloaded/stored ISO files with

apt-cdrom add -m /path/to/your/file.iso

This way everything from Debian could be installed without even having an Internet connection.

Post reply on HN