Engineering for Slow Internet

Original Article ↗ Hacker News Discussion ↗

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.