Engineering for Slow Internet
Engineers and users argue that software should be designed to work reliably on slow, high-latency, and intermittent connections, not just on fast urban broadband. Experiences from Antarctica, ships, rural areas, subways, and developing countries highlight how heavy JavaScript apps, short timeouts, telemetry, and constant updates make many modern tools unusable, while lean or offline‑first systems like WhatsApp, CLI tools, and static sites perform well. Commenters call for systematic testing under degraded network conditions, prioritizing core functionality over tracking and UI fluff, and revisiting local‑first and lightweight web architectures so services remain usable for billions of people with constrained connectivity.
Role of Starlink and Network Infrastructure
- Some argue LEO constellations (e.g. Starlink) “solve” remote bandwidth/latency, citing solid video calls in the Arctic and at sea.
- Others counter: Starlink has jitter, packet loss, sparse polar coverage, high power draw, and is unlikely to scale to billions or be politically permitted everywhere.
- Even with better backhaul, problems remain in congested trains, subways, cities, hotels, and countries with weak or censored infrastructure.
How Common “Slow Internet” Really Is
- Many report unusable mobile data in major cities (US, UK, Germany, France), subways, rural areas, and developing regions.
- 2G/EDGE fallback, capped data plans, overloaded cells, and spotty Wi‑Fi make “slow/bad internet” routine, not exotic.
- Slow or old devices amplify the problem; heavy JS and complex DOMs crush low-end phones.
Bad vs Good Behavior on Poor Networks
- Numerous complaints about heavyweight web apps and tools (chat, project management, cloud consoles, RDP, etc.):
- Huge JS bundles (tens of MB), many round trips, hardcoded short timeouts, no resume, and failure under packet loss.
- Apps that block UI, reload themselves, or lose state when connectivity flickers.
- WhatsApp (and some other messengers) are repeatedly cited as exemplars:
- Offline-first, phone as source of truth, small wire formats, prioritizing messages over telemetry, background sync, robust handling of DNS/MTU issues.
Design Patterns and Proposed Solutions
- Strong support for offline-first / local-first design: transactional sync, conflict resolution, explicit “sync” controls, and local caches.
- Mention of DTN/NNCP, torrents, HTTP range requests, and streaming/incremental rendering as robust patterns.
- New protocol ideas (e.g. Braid HTTP extensions) discussed; some see promise, others view more protocol complexity as missing the real problem (bloat and telemetry).
Testing, Culture, and Incentives
- Many note devs test on fast fiber and new laptops, rarely throttle or simulate jitter/packet loss, and are incentivized for features and tracking, not resilience.
- Calls to routinely test on: slow/high-latency links, metered connections, old phones, and low-end hardware.
- Skepticism that big companies will prioritize this without explicit requirements or user segments that materially affect revenue.