775: Components We Need on Every Project

Episode Summary

Executive Summary: The episode explores common UI/app components that developers repeatedly need—navigation, headers, toasts, portals/popovers, drawers, auth forms, dialogs/modals, confirm flows, admin tools, sharing, markdown, tabs, menus, loading states, and accordions—while debating when to build versus import. The hosts emphasize modern browser APIs (dialog, popover, anchor, logical properties) that reduce JavaScript and improve UX, but argue many components still deserve custom wrappers or reusable local libraries.

Main Topics: Navigation and header patterns: They debate building one responsive nav versus separate desktop/mobile navs, noting that shared HTML plus CSS is ideal when possible, but different structures sometimes justify two components. They also discuss fixed versus non-fixed headers and the drawbacks of sticky headers that waste screen space. Toast notifications and positioning: Toasts are presented as essential across projects. They discuss feature-rich libraries (auto-dismiss, swiping, pause-on-hover) and using CSS logical properties and inset positioning to place toasts more robustly, especially for different writing modes and screen sizes. Portals, popover, dialog, and modals: A large section covers the shift from framework portals to native browser features. Popover and dialog are framed as reducing JavaScript and moving UI into the top layer, while anchors will eventually help with positioning tooltips, menus, and overlays. Reusable interactive components: Drawers, confirm flows, admin menus, user menus, dropdowns, tabs, accordions, and loading indicators are discussed as recurring components that often get copied across projects or imported from libraries due to edge cases and UX complexity. Auth flows and user experience: They argue login/signup forms are typically stable enough to reuse across projects, but user experience matters: avoid overly complicated auth, support autofill, and consider passkeys. They criticize magic links for adding friction for users, despite being convenient for developers. Local component libraries and starter kits: The episode closes on the value of building a personal starter kit or local package system. They suggest developers can improve by implementing these common components themselves at least once, even if they later rely on external libraries for speed. Browser APIs changing component needs: Modern features like dialog, popover, anchor positioning, and logical properties are highlighted as making previously complex UI patterns simpler and more native, reducing the need for heavy component libraries.

Key Arguments: Responsive navigation should default to a single component with CSS handling layout changes; separate desktop/mobile navs should be a last resort when the HTML structure truly differs. Fixed headers are usually unnecessary and waste valuable vertical space unless they provide persistent context, such as code/file metadata on GitHub. Toast systems are now a near-universal need; good implementations should support auto-dismiss, swiping, hover pause, and accessible positioning. Popover and dialog APIs reduce dependence on portals and custom overlay logic by moving content into the browser’s top layer and handling many behaviors natively. Drawers are best bought rather than built in many cases because gesture handling, dismissal, and responsiveness introduce many edge cases. Auth forms are highly reusable across products, but developers should prioritize easy login, autofill, and fewer steps; magic links are more convenient for developers than users. Local component packages or starter kits can speed development while still allowing modification, and building these common components from scratch is a strong way to improve as a developer. Admin tools, tables, share widgets, markdown renderers, and loading states are recurring application patterns that benefit from reusable internal components. Browser-native features are increasingly good enough to replace custom JavaScript-heavy solutions, but many teams still need wrappers for consistent design and behavior.

Data Points: Toast position options: Top, bottom, left, right, center, inline-start, inline-end - Discussed while explaining logical CSS properties and toast placement flexibility Auth friction: 10 minutes - Wes suggests users should get about 10 minutes to correct an emailed login or receipt address Auth support share: 10%–20% - Scott estimates a sizable portion of support comes from users saying they bought something but never got the email Monitor size: 32-inch 4K - Used as an example of why toasts can be missed if placed too far from the main interaction area Keyboard app cost: $4 - Clack, the mechanical keyboard sound app, is described as costing four bucks Breakpoint concern: 1024 - Used as an example of sites switching to hamburger menus too early on desktop-sized windows

Pivotal Quotes: "I almost always roll it myself because they're really not all that complex." — Wes: On building navigation components rather than copying them everywhere "If you want to become a better developer, take this list of common components that we're talking about and just go one by one and build them all." — Scott: Advice on learning by implementing common UI patterns yourself "The browser is actually moving towards giving us those. But we're not there yet." — Wes: On the broader shift toward native browser components replacing custom ones

Implications: Developers can increasingly rely on native browser primitives, but reusable internal components and thoughtful UX decisions still matter. Teams that understand when to build, wrap, or import will ship faster and create better interfaces.