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

211–220 of 406 posts

Re: Engineering for Slow Internet

#211

Post by skydhash »

FridgeSeal wrote: post #147
nrabulinski wrote: post #128

Earlier quoted context omitted.

Yeah, right. GitHub migrated from serving static sites to displaying everything dynamically and it’s basically unusable nowadays. Unbelievably long load times, frustratingly unresponsive, and that’s on my top spec m1 MacBook Pro connected to a router with fiber connection. Let’s not kid ourselves, no matter how many fancy features, splitting, optimizing, whatever you do, JS webapps may be an upgrade for developers, t…

Every time I click a link in GitHub, and watch their _stupid_ SPA “my internal loading bar is better than yours” I despair. It’s never faster than simply reloading the page. I don’t know what they were thinking, but they shouldn’t have.

I have an instance of Forgejo and it’s so snappy. Even though I’m the only user, but the server is only 2GB, 2vcores with other services present. Itp

On the other side, Gitlab doesn’t work with JS disabled.

Re: Engineering for Slow Internet

#212

Post by jimmaswell »

luuurker wrote: post #208

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…

Shutting down 3G was a mistake. Besides turning so many devices into e-waste, it was a good backup when 4g was congested.

Re: Engineering for Slow Internet

#213

Post by HPsquared »

jimmaswell wrote: post #212
luuurker wrote: post #208

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…

Shutting down 3G was a mistake. Besides turning so many devices into e-waste, it was a good backup when 4g was congested.

The lower-bandwidth connections get completely saturated by modern phones with modern data allowances. Back in the day I had 500MB a month on 3G, for instance. I can use that in a few minutes these days.

Re: Engineering for Slow Internet

#214

Post by bombcar »

camel-cdr wrote: post #62
danpalmer wrote: post #9

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

It's not only the services them self. I have a very slow mobile connection, and one thing that bothered me immensly is downloading images in the browser: How is it, than when I go to a .jpg url to view an image in the browser it takes way longer and sometimes times out, than hopping over to termux and running wget. I had this problem with both firefox and chrome based browsers. Note that even the wget download usuall…

Browsers usually try to multiplex things, sometimes even the same image if the server supports "get specific byte range" or whatever.

There may be a setting to turn a browser back into a dumb wget visual displayer.

Re: Engineering for Slow Internet

#215

Post by bombcar »

pimeys wrote: post #31
danpalmer wrote: post #9

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

WiFi at a stop is as easy as putting up a few wireless routers, it's a bit more complex than at home but the same general idea.

Wifi inside the trains involves much more work, and to get them to ALSO be seamless across the entire setup - even harder. Easily 10x or 100x the cost.

It's sad, because the Internet shouldn't be that bad when the network drops all the time; it should just be slower as it waits to send good data.

Re: Engineering for Slow Internet

#216

Post by taeric »

tecleandor wrote: post #134
mwcampbell wrote: post #122

Earlier quoted context omitted.

False dichotomy, with what is likely extreme hyperbole on the JS side. Are there actual sites that ship 20 MB, or even 5 MB or more, of frameworks? One can fit a lot of useful functionality in 100 KB or less of JS< especially minified and gzipped.

Well, I'm working right now so let me check our daily "productivity" sites (with an adblocker installed): - Google Mail: Inbox is ~18MB (~6MB Compressed). Of that, 2.5MB is CSS (!) and the rest is mostly JS - Google Calendar: 30% lower, but more or less the same proportions - Confluence: Home is ~32MB (~5MB Comp.). There's easily 20MB of Javascript and at least 5MB of JSON. - Jira: Home is ~35MB (~7MB compressed). I…

This is mind blowing to me. I expect that the majority of any application will be the assets and content. And megabytes of CSS is something I can't imagine. Not the least for what it implies about the DOM structure of the site. Just, what!? Wow.

Re: Engineering for Slow Internet

#217

Post by bombcar »

lawgimenez wrote: post #102

From where I'm from (Southeast Asia), slow internet is common in provincial and remote areas. It's like the OP's experience in South Pole but slower. That's why I always cringe at these fancy-looking UI cross-platform apps since I know they will never work in a remote environment. Also, that is why offline support is very important. I only use Apple Notes and Things 3, both work tremendously in such remote settings.…

What's sad is that the app-style setup on phones SHOULD be perfect for this - you download the app when you DO have a good connection, and then when you're out on the slow/intermittent connection the ONLY thing the app is sending is the new data needed.

Instead almost all apps are just a bad web browser that goes to one webpage.

Re: Engineering for Slow Internet

#218

Post by toast0 »

erinaceousjones wrote: post #98
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…

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…

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

It's not exactly XMPP, it started with XMPP, but XML is big, so it's tokenized (some details are published in the European Market Access documentation), and there's no need for interop with standard XMPP clients, so login sequence is I think way different.

But it runs on port 5222? by default (with fallbacks to port 443 and 80).

I think GCM or whatever it's called today is plain XMPP (including, optionally, on the server to server side), and runs on ports 5228-5230. Not sure what protocol apple push is, but they use port 5223 which is affiliated with xmpp over tls.

So I think using a non 443 port was helpful for your QoS? But being avaialable on port 443 is helpful for getting through blanket firewall rules. AOL used to run AIM on all the ports, which is even better at getting through firewalls.

Re: Engineering for Slow Internet

#219

Post by HPsquared »

throwaway211 wrote: post #206
danpalmer wrote: post #9

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

London fails to provide a lot of essentials.

Re: Engineering for Slow Internet

#220

Post by marcosdumay »

pnt12 wrote: post #185
klabb3 wrote: 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.

> fixing the bumpy road may help

It really wouldn't. Lousy drivers are a way thinner bottleneck than the roads.

But it will improve the services where the drivers are good.

If the protocol is actually any good (its goals by themselves already make me suspicious it won't be), the well-designed web-apps out there can become even better designed. But it absolutely won't improve the situation people are complaining about.

Post reply on HN