Hasty Treat - Developing for Slow and Spotty Connections

Episode Summary

Executive Summary: The episode examines how web apps should be designed for slow, high-latency, or unreliable internet connections. Scott and Wes discuss offline support via service workers, thoughtful loading states, cancellation and failure handling for XHR/fetch, and clear progress feedback for long uploads. The core message: developers often build on fast local networks and miss real-world constraints, so resilient UX must account for interruptions, limited data, and uncertainty.

Main Topics: Designing for slow and unreliable networks: The hosts distinguish between slow download, slow upload, high latency, and intermittent connectivity, emphasizing that real users frequently face degraded network conditions that developers overlook on fast office or local setups. Offline support with service workers: They recommend caching essential content with a service worker so users can still access useful information when offline or out of data, while noting service workers can be risky to launch with if misconfigured. Loading states and perceived performance: The discussion covers skeleton screens, spinners, and delayed loaders, arguing that loading UI should improve perception without flashing unnecessarily or causing layout shifts. Granular UI feedback during form interactions: They critique forms that block the entire interface while loading dependent fields, and note the importance of showing local, contextual feedback when changing values like country/state selections. Handling XHR/fetch failures and cancellations: The hosts stress the need to cancel obsolete requests, handle failures when connectivity drops, and use state-aware logic so apps don’t assume success or leave users stuck in ambiguous states. Progress reporting for long uploads: They discuss the frustration of uploads that appear complete but are still processing, advocating for trustworthy progress indicators and status messages that clarify whether work is ongoing.

Key Arguments: Developers often fail to consider poor connections because local development environments are usually fast and reliable. Offline-first patterns can preserve essential functionality for users with no signal or limited data plans. Skeleton screens are useful when delays are real, but they should not appear instantly for very fast requests or they become annoying. Blocking an entire form or page for a small async request is poor UX; loading indicators should be localized and specific. Requests can fail or become obsolete mid-flight, so applications should handle cancellation and error states explicitly. Long uploads need honest progress feedback; fake or stalled progress bars erode trust and leave users unsure whether work is still happening.

Data Points: Service worker cache availability: Offline access to cached site content - Wes describes a site still working when his internet connection dropped because of service-worker caching. Download speed example: 0.6 megabits up - Wes cites his current slow upload speed while working from a cottage with poor internet. Typical wired speed example: about 700 megabits per second - Scott mentions his Ethernet speed at the office, noting it is below the advertised gigabit. Advertised connection speed: 1028 megabits per second - Scott jokes about his gigabit connection being marketed as over 1 Gbps. Service worker free trial: 14 days - LogRocket sponsorship offer mentioned at the start of the episode. Video upload duration example: 15 minutes - They describe a 6–7 MB image upload on a slow connection taking a long time. Upload size example: 6 or 7 meg image - Used to illustrate how small files can still take a long time on poor connections. Backup feedback example: 400,000 files - Wes references Backblaze showing a very large number of remaining files after an npm install.

Pivotal Quotes: "the web isn't always the high-powered gigabit speeds that sometimes we get to develop on in our fancy offices" — Scott Tolinski: Introduces the episode’s central premise: developers must design for real-world network conditions. "show this loading component while these ones are being pulled in from the network" — Wes Bos: Describes the loading-threshold concept for dynamic imports and Suspense-like behavior. "why don't you let me know about that, right?" — Scott Tolinski: Expresses frustration with upload UIs that appear complete without explaining what is actually happening.

Implications: Web apps should be resilient by default: offline-capable where possible, explicit about loading and failure, and honest about long-running work. Better network-aware UX reduces frustration and makes apps usable for more people in more conditions.