Live data from Hacker News

Engineering for Slow Internet

brr.fyi

81–90 of 406 posts

Re: Engineering for Slow Internet

#81

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, server-rendering definitely helps, though I have suspicions about its compiled outputs still being very heavy. There's also a lot of CSS frameworks that have an inline-first paradigm meaning there's no saving for the browser in downloading a single stylesheet. But I'm not sure about that.

Re: Engineering for Slow Internet

#82
post #76
post #72

Earlier quoted context omitted.

Sounds like what would benefit you is a HTMX approach to the web.

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

Re: Engineering for Slow Internet

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

Re: Engineering for Slow Internet

#85

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…

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 do, and there is almost no online resources that you can base your projects on if you’re a Google/GPT programmer. Part of this is because of the ocean of terrible JS resources online, but a big part of it is also that the organisations which work like this aren’t sharing. We have 0 public resources for the way we work as an example, because why would we hand that info to our competition?

Re: Engineering for Slow Internet

#86

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.

The author puts a lot of effort into emphasizing that it's not just "a handful of people in Antarctica" facing such issues, but quite a noticeable percentage of global population with unstable or otherwise weird connectivity. The internet shouldn't be gatekept from people behind such limitations and reserved for the convenient "target audience" of companies, whoever that might be - especially when solutions to these problems are largely trivial (as presented in the article) and don't require that much "engineering effort" for companies of that scale, since they are already half-implemented, just not exposed to users.

People should not be limited from employing already existing infrastructure to overcome their edge-case troubles just because that infrastructure is not exposed due to it being unnecessary to the "majority of the clients".

Re: Engineering for Slow Internet

#87
post #34
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.

They did if you were on o2, that's why I'm still with Aldi Talk (they use the o2 network); they've had LTE through the entire network for a while now. The new thing is 5G for everyone.

Re: Engineering for Slow Internet

#88
I cringe whenever I think how blazing fast things could be today if only we hadn't bloated the web by 1000x.

In the dial-up era things used to be unworldly fast merely by getting access to something like 10M ethernet. Now mobile connections are way, way faster than physical connections in the 90's but web pages aren't few KB, they are few MB at minimum.

It takes four seconds and 2.5 MB to load my local meteorological institute's weather page which changes not more often than maybe once an hour and could be cached and served as a static base page in a few dozen milliseconds (i.e. instantly). A modern connection that's plenty capable to support all my remote work and development over a VPN and interactive shells without any lag can't help me get modern web pages load any faster because of the amount of data and the required processing/execution of a million lines of javascript that's imported from a bunch of number of sources, with the appropriate handshake delays of new connections implied, for each page load.

A weather page from 2004 served exactly the same information as a weather page from 2024, and that information is everything required to get a sufficient glimpse of today's weather. One web page could be fixed but there are billions of URIs that load poorly. The overall user experience hasn't improved much, if at all. Yes, you can stream 4K video without any problems which reveals how fast things actually are today but you won't see it when browsing common pages -- I'd actually like to say web pages have only gone slower despite the improvements in bandwidth and processing power.

When many pages still had mobile versions it was occasionally a very welcome alternative. Either the mobile version was so crappy you wanted to use the desktop version on your phone, or it was so good you wanted to predominantly load the mobile version even on desktop.

I'd love to see an information internet where things like weather data, news articles, forum posts, etc. would be downloadable as snippets of plaintext, presumably intended to be machine readable, and "web" would actually be a www site that builds a presentation and UI for loading and viewing these snippets. You could use whichever "web" you want but you would still ultimately see the same information. This would disconnect information sources from the presentation which I think is the reason web sites started considering "browser" a programmable platform, thus taking away user control and each site bloating their pages each individually, leaving no choice for the user but maybe some 3rd party monkeyscripts or forced CSS rules.

If the end user could always choose the presentation, the user would be greatly empowered in comparison to the current state of affairs where web users are currently being tamed down to be mere receivers or consumers of information, much not unlike passive TV viewers.

Re: Engineering for Slow Internet

#89
post #72

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…

Sounds like what would benefit you is a HTMX approach to the web.

It sounds like GP would benefit from satellite internet bypassing the firewall, but I don't know how hard the Chinese government works to crack down on that loophole.

Re: Engineering for Slow Internet

#90

Earlier quoted context omitted.

Whether you like it or not, over 15% of the world's population lives in China.

I guess they should fix their government, then.

And uncensored websites that function through the great firewall would help organize that government fixing.
Post reply on HN