Live data from Hacker News

Engineering for Slow Internet

brr.fyi

351–360 of 406 posts

Re: Engineering for Slow Internet

#351
post #350

Earlier quoted context omitted.

Phone signal? Okay. I thought we're talking about fixed broadband connections.

Ditto; I don't think fiber it's available at $LOST_REMOTE_FARMLAND_VILLAGE.

This is increasingly often the case. Also, don't forget that modern WISP equipment allows for 100Mbps+ speeds for a price next to nothing (Ubiquiti, MikroTik).

Re: Engineering for Slow Internet

#352
post #185
post #166

Earlier quoted context omitted.

Grump take: More complex technology will not fix a business-social problem. In fact, you have to go out of your way to make things this shitty. It’s not hard to build things with few round trips and less bloat, it’s much easier. The bloat is there for completely different reasons. Sometimes the bloat is unnoticeable on juicy machines and fast internet close to the DC. You can simulate that easily, but it requires the…

> Generally, ad-tech and friends cares very little about small cohorts of users. Sure, and it will keep being that way. But if this gets improved at the transport layer, seems like a win. As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior.

>As an analogy, if buses are late because roads are bumpy and drivers are lousy, fixing the bumpy road may help, even if drivers don't change their behavior

No. It will make things worse, because now lousy drivers are no longer constrained by the bumpy road, so they will become even lousier.

Case in point: software is shittier than ever, despite the 100x increase in computer performance since the 90s.

Re: Engineering for Slow Internet

#353
post #336

Earlier quoted context omitted.

Yeah, but your blog is not a full featured chat system with integrated audio and video calling, strapped on top of a document format. There are a few architectural/policy problems in web browsers that cause this kind of expansion: 1. Browsers can update large binaries asynchronously (=instant from the user's perspective) but this feature is only very recently available to web apps via obscure caching headers and most…

The privacy issues aren't just hypothetical, but that aside, that caching model unfortunately doesn't mesh well with modern webdev. It requires all dependencies to be shipped in full, no tree shaking to only include the needed functions. And separately as individual files.. and for people to actually stick to the same versions of dependencies

Can you show some real sites that were mounting such attacks using libraries?

Re: Engineering for Slow Internet

#355
post #137

Earlier quoted context omitted.

"I feel like some devs need to time-travel back to 2005 or something and develop for that era in order to learn how to build things nimbly." No need to invent time travel, just let them have a working retreat somewhere with only bad mobile connection for a few days.

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.

Re: Engineering for Slow Internet

#356

Earlier quoted context omitted.

This makes perfect sense in theory and yet it's the opposite of my experience in practice. I don't know how, but SPA websites are pretty much always much more laggy than just plain HTML, even if there are a lot of page loads.

It often is that way, but it's not for technical reasons. They're just poorly written. A lot of apps are written by inexperienced teams under time pressure and that's what you're seeing. Such teams are unlikely to choose plain server-side rendering because it's not the trendy thing to do. But SPAs absolutely can be done well. For simple apps (HN is a good example) you won't get too much benefit, but for more highly i…

An SPA I use not infrequently is the online catalog on https://segor.de (it's a small store for electronics components). When you open it, it downloads the entire catalog, some tens of MB of I-guess-it-predates-JSON, and then all navigation and filtering is local and very fast.

Re: Engineering for Slow Internet

#357
post #348

A fascinating article and I need to revisit this when I have more time. So, all I'd say now is that there's way too much emphasis on GUI. Also, check out some of the web sites on https://1mb.club - it's amazing what can be achieved in less than 1Mb of HTML ...

1 MB is comically large. 150 kb is a much more interesting target.

Haha .. I just rechecked mine and it's coming in as just under 20Kb - must be the pie-chart graphic bloating it out

Re: Engineering for Slow Internet

#358

Earlier quoted context omitted.

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…

Yes - a thousand yeses. I once got asked "what was a life changing company/product" and my answer was WhatsApp - to slightly bemused looks. WhatsApp connected the world for free. Obviously they weren't the first to try but when my (very globally distributed family) picked up WhatsApp in '09/'10 we knew we were onto something different. Being able to stay in touch with my brother half way across the world in realtime…

> Email felt clunky and oddly formal - email clients don't feel "chatty".

Now (in 2024) have you tried Delta Chat?

Re: Engineering for Slow Internet

#359
post #105

Earlier quoted context omitted.

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.

Yeah, admittedly this year I've also started experiencing holes on the ringbahn (strangely and consistently around frankfurter allee), but the ubahn has been fine. I'm with sim.de which I believe is essentially an O2 reseller (apn references o2)

Gesundbrunnen too.

Re: Engineering for Slow Internet

#360

Earlier quoted context omitted.

The size of HTMX compressed is 10kb and very rarely changes which means it can stay in your cache for a very long time.

I'm embedded so I don't much about web stuff but sometimes I create dashboards to monitor services just for our team, tganks for introducing me to htmx. I do think html+css should be used for anything that is a document or static for longer than a typical view lasts. Arxiv is leaning towards HTML+css vs latex in acknowledgement that paper is no longer how "papers" are read. And on the other end, eBay works really wel…

You would have to replace the whole graph everytime. Probably works if it updates once per minute. But more than that it might be time to look at some small js plot library to update the graph.
Post reply on HN