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

91–100 of 406 posts

Re: Engineering for Slow Internet

#91

Post by rkachowski »

pintxo wrote: post #34
pimeys wrote: post #31

Earlier quoted context omitted.

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...

Berlin did not have mobile connections inside the tunnels until very recently (this year, I believe). This included the trains not being connected to any outside network. Thus wifi on the subway was useless to implement.

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.

Re: Engineering for Slow Internet

#92

Post by xandrius »

throw46365 wrote: post #37
oefrha wrote: post #33

Earlier quoted context omitted.

As a web developer you can just throttle your connection in developer tools though, no self-limiting required. But nobody does that in big corporations building most of the sites needed by people with slow connections.

Yeah, though it doesn’t quite capture all of the experience of working with slower broadband. For example if you have a website that is meant to be used alongside a video call or while watching video, it’s difficult to really simulate all of that “feel”. Using a link that is slow in practice is an invaluable experience.

You can install programs at software level to emulate it as a whole. I remember using one for OSX and it working pretty well.

Re: Engineering for Slow Internet

#93

Post by tleb_ »

sethammons wrote: post #82
tleb_ wrote: post #76

Earlier quoted context omitted.

What about plain HTML & CSS for all the websites where this approach is sufficient? Then apply HTMX or any other approach for the few websites that are and need to be dynamic.

That is exactly what htmx is and does. Everything is rendered server side and sections of the page that you need to be dynamic and respond to clicks to fetch more data have some added attributes

I see two differences: (1) the software stack on the server side and (2) I guess there is JS to be sent to the client side for HTMX support(?). Both those things make a difference.

Re: Engineering for Slow Internet

#94

Post by croes »

HL33tibCe7 wrote: post #83

Why do writers like this feel so entitled to engineering effort from companies? Maybe companies don’t want to plow millions into microoptimising their sites so a handful of people in Antarctica can access them, when the vast majority of their clients can use their sites just fine.

You do realize it's not just Antarctica?

There are lots of places in the world where the internet speed isn't great.

I'm actually experiencing slow internet right now and I' m in Germany.

Re: Engineering for Slow Internet

#95

Post by xenodium »

Not yet officially launched, but I’m working on a no-bloat, no-tracking, no-JS… blogging platform, powered by a drag/drop markdown file: https://lmno.lol

Blogs can be read from just about any device (or your favourite terminal). My blog, as an example: https://lmno.lol/alvaro

Shared more details at https://indieweb.social/@xenodium/112265481282475542

ps. If keen to join as an early adopter, email help at lmno.lol

Re: Engineering for Slow Internet

#96

Post by noprocrasted »

toast0 wrote: post #52
chipdart wrote: post #36

Earlier quoted context omitted.

> In Australia you're just 200ms from everything most of the time. (...) > The only app that I am always impressed with is WhatsApp. It's always the first app to start working after a reconnect, the last to get any traffic through before a disconnect, and even with the latency, calls feel pretty fast. The 200ms is telling. I bet that WhatsApp is one of the rare services you use which actually deployed servers to Aust…

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

> prioritize messages over telemetry

This is a big one that makes low-bandwidth connections unusable in a lot of apps. The deluge of ad/tracking/telemetry SDKs' requests all being fired in parallel with the main business-logic requests makes them all saturate the slow pipe and usually leads to all of them timing out. By being third-party SDKs they may not even give you control of the underlying network requests nor the ability to buffer/delay/cache those requests.

One advantage of being Facebook in this case is that they're the masters of spyware and are unlikely to need to embed third-party spyware, so they can blend tracking/telemetry traffic within their business logic traffic and apply prioritization, including buffering any telemetry and sending it during less critical times.

Re: Engineering for Slow Internet

#97

Post by noprocrasted »

themoonisachees wrote: post #79
drozycki wrote: post #41

Earlier quoted context omitted.

I get 400 Mbps down standing at the door of that same diner. My understanding is that 4G bands are repurposed for 5G in rough proportion to the usage of 4G vs 5G devices at that tower, plus there’s some way to use a band for both. In any case I was having these indoor performance issues back in 2019. I’m pretty sure it’s an Intel issue, and any Qualcomm modem would be fine.

I see this in my french city, there's a particular spot on my commute where my phone (mediatek) will report 2 bars of 5G but speeds will actually be around 3G. I've also noticed other people on the tram having their videos buffer at that spot, so it's not just me. The carriers do not care, of course. I think there's just some of these areas where operational conditions make the towers break in some specific way.

[dead]

Re: Engineering for Slow Internet

#98

Post by erinaceousjones »

toast0 wrote: post #52
chipdart wrote: post #36

Earlier quoted context omitted.

> In Australia you're just 200ms from everything most of the time. (...) > The only app that I am always impressed with is WhatsApp. It's always the first app to start working after a reconnect, the last to get any traffic through before a disconnect, and even with the latency, calls feel pretty fast. The 200ms is telling. I bet that WhatsApp is one of the rare services you use which actually deployed servers to Aust…

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

WhatsApp is (or was) using XMPP for the chat part too, right?

When I was IT person on a research ship, WhatsApp was a nice easy one to get working with our "50+ people sharing two 256kbps uplinks" internet. Big part of that was being able to QoS prioritise the XMPP traffic which WhatsApp was a big part of.

Not having to come up with filters for HTTPS for IP ranges belonging to general-use CDNs that managed to hit the right blocks used by that app, was a definite boon. That, and the fact XMPP was nice and lightweight.

As far as I know google cloud messaging (GCN? GCM? firebase? Play notifications? Notifications by Google? Google Play Android Notifications Service?) also did/does use XMPP, so we often had the bizarre and infuriating very fast notifications _where sometimes the content was in the notification_ but when you clicked on it, other apps would fail to load it due to the congestion and latency and hardcoded timeouts TFA mentions.. argh.

But WhatsApp pretty much always worked, as long as the ship had an active WAN connection.... And that kept us all happy, because we could reach our families.

Re: Engineering for Slow Internet

#99

Post by chrisldgk »

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?)

Yes, though server side rendering is everything but a new thing in the react world. NextJS, Remix, Astro and many other frameworks and approaches exist (and have done so for at least five years) to make sure pages are small and efficient to load.

Re: Engineering for Slow Internet

#100

Post by Thlom »

polairscience wrote: post #15
0xWTF wrote: post #2

I still think engineering for slow internet is really important, and massively under appreciated by most software developers, but ... LEO systems (like Starlink, especially StarLink) essentially solve the core problems now. I did an Arctic transit (Alaska to Norway) in September and October of 2023, and we could make FaceTime video calls from the ship, way above the Arctic Circle, despite cloud cover, being quite far…

What ship were you on and was it the northwest passage? We haven't had good luck north of 80 degrees with starlink.

FYI, Space Norway will launch two satellites this summer on a Falcon 9 that will be going in a HEO orbit, among the payloads on the satellites is a Viasat/Inmarsat Ka-band payload which will provide coverage north of 80 degrees. Latency will probably be GEO+, but coverage is coverage I guess. :-)
Post reply on HN