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

121–130 of 406 posts

Re: Engineering for Slow Internet

#121

Post by ajsnigrutin »

Slow internet and also slow devices!

If you're targeting the general population (so, chat service, banking app, utility app,...), you should be targeting the majority of users, not just the new-flagship ones, so all the testing should be done on a cheapest smartphone you could buy in a supermarket two years ago (because well.. that's what "grandmas" use). Then downgrade the connection to 3g, or maybe even edge speeds (can be smulated on network devices), and the app/service should still work.

Somehow it seems that devs get the best new flagships only, optimize the software for that, and forget about the rest... and I understand that for a 3d shooter game or something, but an eg. banking app, should work on older devices too!

Re: Engineering for Slow Internet

#122

Post by mwcampbell »

bayindirh wrote: post #118
mike_hearn wrote: post #116

Earlier quoted context omitted.

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.

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.

Re: Engineering for Slow Internet

#123

Post by victorbjorklund »

tleb_ wrote: post #93
sethammons wrote: post #82

Earlier quoted context omitted.

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.

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

Re: Engineering for Slow Internet

#124

Post by andrepd »

bayindirh wrote: post #118
mike_hearn wrote: post #116

Earlier quoted context omitted.

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.

Yes. It's inexcusable that text and images and video pulls in megabytes of dependencies from dozens of domains. It's wasteful on every front: network, battery, and it's also SLOW.

Re: Engineering for Slow Internet

#125

Post by andrepd »

vmfunction wrote: post #110
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…

>A lot of this resonates. I'm not in Antartica, I'm in Beijing, but still struggle with the internet. Not even that, with outer space travel, we all need to build for very slow internet and long latency. Devs do need to time-travel back to 2005.

I'm sure this is not what you meant but made me lol anyways: sv techbros would sooner plan for "outer space internet" than give a shit about the billions of people with bad internet and/or a phone older than 5 years.

Re: Engineering for Slow Internet

#126

Post by sitkack »

jiggawatts wrote: post #115
padolsey wrote: post #54

Earlier quoted context omitted.

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?

> Most of the former Soviet Block governments fell without any bloodshed.

That was Gorbachev. Most leaders of any country would roll tanks.

Re: Engineering for Slow Internet

#127

Post by Karrot_Kream »

So I've hacked a lot on networking things over the years and have spent time getting my own "slow internet" cases working. Nothing as interesting as McMurdo by far but I've chatted and watched YouTube videos on international flights, trains through the middle of nowhere, crappy rural hotels, and through tunnels.

If you have access/the power (since these tend to be power hungry) to a general-purpose computing device and are willing to roll your own my suggestion is to use NNCP [1]. NNCP can can take data, chunk it, then send it. It also comes with a sync protocol that uses noise (though I can't remember if this enables 0RTT) over TCP (no TLS needed so only 1.5 RTT time spent establishing connection) and sends chunks, retrying failed chunks along the way.

NNCP supports feeding data as stdin to a remote program. I wrote a YouTube downloader, a Slack bot, a Telegram bot, and a Discord bot that reads incoming data and interacts with the appropriate services. On the local machine I have a local Matrix (Dendrite) server and bot running which sends data to the appropriate remote service via NNCP. You'll still want to hope (or experiment such) that MTU/MSS along your path is as low as possible to support frequent TCP level retries, but this setup has never really failed me wherever I go and let's me consume media and chat.

The most annoying thing on an international flight is that the NNCP endpoint isn't geographically distributed and depending on the route your packets end up taking to the endpoint, this could add a lot of latency and jitter. I try to locate my NNCP endpoint near my destination but based on the flight's WiFi the actual path may be terrible. NNCP now has Yggdrasil support which may ameliorate this (and help control MTU issues) but I've never tried Ygg under these conditions.

[1]: http://www.nncpgo.org/

Re: Engineering for Slow Internet

#128

Post by nrabulinski »

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.

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, they’re a huge downgrade for users in all aspects

Re: Engineering for Slow Internet

#130

Post by hooby »

All of that sounds like, that torrent-based updaters/downloaders should be the absolute killer-app for environments like that.

Infinitely resume-able, never looses progress, remains completely unfazed by timeouts, connection loss, etc. - and the ability to share received update-data between multiple devices peer-to-peer.

Post reply on HN