Live data from Hacker News

Engineering for Slow Internet

brr.fyi

371–380 of 406 posts

Re: Engineering for Slow Internet

#371
post #292

Earlier quoted context omitted.

Amen to this. And give them a mobile cell plan with 1GB of data per month. I've seen some web sites with 250MB payloads on the home page due to ads and pre-loading videos. I work with parolees who get free government cell phones and then burn through the 3GB/mo of data within three days. Then they can't apply for jobs, get bus times, rent a bike, top up their subway card, get directions.

Having an adblocker (firefox mobile works with uBlock origin) and completely deactivate loading of images and videos can get you quite far with limited connection.

I strongly suspect that the venn diagram of people that know how to minimize data usage, and indigent people being given free cell phones with limited data has precious little overlap.

Re: Engineering for Slow Internet

#372
At the beginning of learning to code in 2017 I was living in the Caribbean. I had to get Xcode command line tools installed, In a place like that there are some sites that just don’t work sometimes because it is clear that the devs have never thought about what happens when a significant portion of your requests fail.

Re: Engineering for Slow Internet

#373

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…

The amount of complexity to generate HTML/JS is a little staggering sometimes for the majority of simple use cases.

Using Facebook level architectures for actually pretty basic needs can be like hitting an ant-sized problem with a sledgehammer and wondering why the sledgehammer is so heavy and awkward to swing for little things.

Re: Engineering for Slow Internet

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

Very true, Javascript was never meant to be mandatory for web pages.

Two of the lighter options right now though seem to be things like alpinejs, htmx, etc. Basic building blocks where / if needed.

Re: Engineering for Slow Internet

#375

Earlier quoted context omitted.

Amen to this. And give them a mobile cell plan with 1GB of data per month. I've seen some web sites with 250MB payloads on the home page due to ads and pre-loading videos. I work with parolees who get free government cell phones and then burn through the 3GB/mo of data within three days. Then they can't apply for jobs, get bus times, rent a bike, top up their subway card, get directions.

This is probably a deliberate decision on the part of the government. A lot of the justice system is designed to keep people in prison.

It's not deliberate by the government. And the situation is getting better. Basically some of the telcos being a bit greedy and only giving 3GB/mo data to the users and spending all their profits on paying people in the hoods $20 a pop to sign people up.

Recently I've started to see some contracts with vastly more data, including some unlimiteds.

Re: Engineering for Slow Internet

#376

Earlier quoted context omitted.

uMatrix (unsupported but still works) reduces page weight and compute even more

How so?

it allows javascript on the original site domain, but turns it off for external domains, buts then lets you selectively turn it back on, and remembers what you've selected. Turning off javascript turns off a lot of both addtional downloading and cpu cycles. for impatient people it's tedious, but for minimalists it's heaven.

Re: Engineering for Slow Internet

#377

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

Here in the USA a great number of networks will drop back to 2G when their data plan runs out. And most poor people are on really low data limits, so they spend most of the month on 2G. Try using Google Maps to get around on 2G :(

I can imagine how bad it is.

By the way, Google Maps supports offline maps. If the user can download the map (a few MB for a city), then at least the basic stuff will be fast.

Re: Engineering for Slow Internet

#378
post #362

Earlier quoted context omitted.

This is probably a deliberate decision on the part of the government. A lot of the justice system is designed to keep people in prison.

That makes little sense. If it was a deliberate plan, it would be much more effective (and cheaper) to not provide the cellphones and data plan in the first place.

Exactly. It's easy to attribute malice where incompetence is the answer. The root problem is that there is no feedback loop so that the government agency funding the program isn't properly looking at the product being delivered at the other end and putting measures in place to stop the contractors from taking advantage of the program to only deliver the barest minimum without tracking the effects on the end customer.

Re: Engineering for Slow Internet

#379
post #337
post #253

Earlier quoted context omitted.

Sure, would be interesting to know how it would fare against purpose-made compression under real world conditions still...

gzip is fast. And it was made for real world conditions.

Brotli is a better example, as it was literally purpose made for HTML/CSS/JS. It is now supported basically everywhere for HTTP compression, and uses a huge custom dictionary (about 120KB) that was trained on simulated web traffic.

You can even swap in your own shared dictionary with a HTTP header, but trying to make your own dictionary specific to your content is a fool’s errand, you’ll never amortize the cost in total bits.

What you CAN do with shared dictionaries though, is delta updates.

https://developer.chrome.com/blog/shared-dictionary-compress... https://news.ycombinator.com/item?id=39615198

Re: Engineering for Slow Internet

#380

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…

> It all ends up meaning that, even if I get a connection, it's not stable

I feel you, but the experience can actually be very good if you invest a bit of time looking at Shadowsocks/V2Ray and building your own infra.

Post reply on HN