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.
Engineering for Slow Internet
351–360 of 406 posts
Re: Engineering for Slow Internet
#352Earlier 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.
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
#353Earlier 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
Re: Engineering for Slow Internet
#354Re: Engineering for Slow Internet
#355Earlier 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.
Re: Engineering for Slow Internet
#356Earlier 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…
Re: Engineering for Slow Internet
#357A 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.
Re: Engineering for Slow Internet
#358Earlier 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…
Now (in 2024) have you tried Delta Chat?
Re: Engineering for Slow Internet
#359Earlier 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)
Re: Engineering for Slow Internet
#360Earlier 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…