975: What’s Missing From the Web Platform?

Episode Summary

Executive Summary: Wes and Scott survey what the web platform still lacks despite recent API progress: better native UI primitives, more ergonomic JavaScript syntax, richer browser and device APIs, CSS improvements, and thoughtful AI integration. They favor standards that preserve accessibility and customization while acknowledging some complex interactions will still need libraries. The episode mixes practical wish-listing with caution about compatibility, browser monoculture, and immature AI APIs.

Main Topics: Better browser UI primitives: They argue that common controls like selects, toggles, file uploads, tabs, date pickers, combo boxes, and drag-and-drop still need more stylable, accessible, built-in primitives. The customizable select is praised as a major step forward, but many controls remain awkward or too limited. JavaScript syntax and language ergonomics: The hosts want language features such as type annotations and the pipe operator to reduce boilerplate and improve code readability. They see TypeScript as effectively standard already, but note proposals like types-as-comments and the long-stalled pipe operator. Missing and improved web APIs: They discuss APIs for cookie consent, identity/auth, element-by-text selection, reactive templates, sync/local-first protocols, better database support, text metrics, and more complete form verbs. The theme is making common web tasks less repetitive and more standards-based. CSS evolution and rendering control: Ideas include transition speed in pixels per second, CSS strict mode, text measurement, and better rendering behavior for large lists. They also debate content-visibility and whether browsers should better handle virtualization-like concerns without developer hacks. Hardware and device access on the web: They advocate wider standardization of Bluetooth, Web Serial, NFC, RFID, and sockets-like capabilities for real-device workflows. The goal is making browser-based device control practical without resorting to native apps or ad hoc server bridges. AI access in the browser and runtime APIs: They want native AI APIs that can use local device models, user-loaded models, or remote models interchangeably, but caution that current browser AI APIs are too immature and narrow. They envision AI helping with natural-language date inputs, validation, TTS, and other ergonomic tasks. Browser competition and standards philosophy: They push back on a single-engine web future, arguing that diversity keeps the platform healthy. They also stress that some complex problems should still be solved by libraries or remain browser-agnostic instead of forcing incomplete standards too early.

Key Arguments: The web now has many strong APIs, but key primitives are still missing or too hard to style, so developers keep rebuilding common UI controls in JavaScript. Customizable native components should preserve accessibility and keyboard support while giving full CSS control, rather than forcing a choice between native behavior and custom design. Date pickers, file upload, tabs, toggles, and drag-and-drop are common enough that better built-in primitives would reduce library dependence, but some features are too complex for a single standard control. TypeScript is effectively the default language for many developers, so syntax support in the platform feels overdue, though standards bodies should still be cautious and deliberate. The pipe operator and other syntax proposals would improve readability by reducing nested function wrappers and making data flow clearer. Browser APIs should make recurring tasks like cookie consent, login identity, and text-based element selection more ergonomic and less repetitive. Content-visibility and other browser rendering features should ideally reduce developer hacks around virtualization, even though current implementations are imperfect. AI APIs should not be rushed into a narrow prompt-and-stream model; the better long-term solution is flexible access to local, bundled, or remote models. Some capabilities, especially hardware access and TTS, are already useful in browser-adjacent environments but need broader standardization and better support across runtimes. A monoculture browser ecosystem would harm the web’s evolution, even if having one engine would simplify development in the short term.

Data Points: TypeScript adoption timeframe: "I have not written non-TypeScript in just about, I don't know, when the last time I wrote Python. Seven, eight years?" - Scott describes how long it has been since he wrote plain JavaScript or Python-like non-TypeScript code. Pipe operator proposal status: "stage two" and "last updated three years ago" - Wes notes the current status of the pipe operator proposal. Cookie/privacy example: "a massive project" - Wes references Sentry removing cookies from its platform as part of privacy work. Battery/performance detection: navigator.getBattery API used in Riverside - They cite a real-world example where the browser detected battery power and suggested plugging in for better performance. Virtualization scale example: 20,000 list items - Used to illustrate how content-visibility or virtualization concerns arise with large DOM lists. Text-to-speech cost: 10 cents per 10,000 characters - Wes mentions Alibaba’s Quen TTS pricing as an affordable TTS option. TTS input example: 5,000-word blog post / 5,000 characters - They compare the practical cost of converting long-form content to speech. Local AI performance target: "four or five hundred milliseconds" - They contrast slow current local AI responses with the ideal of near-instant inference.

Pivotal Quotes: ""You do not want a world where there is one browser engine."" — Wes: He argues against Safari moving to Chromium and warns about web stagnation under browser monoculture. ""I feel like TypeScript is JavaScript at this point."" — Scott: Scott explains why language-level support for types feels long overdue. ""The browser will simply just ignore it"" — Wes: Describing the types-as-comments proposal, where TypeScript syntax could exist in the browser without affecting runtime behavior.

Implications: Listener expectations for the web are shifting toward native-grade primitives, better standards, and smarter AI. The industry should standardize carefully, prioritize accessibility and flexibility, and avoid overcommitting to immature APIs or a one-engine future.