Summary of 975: What’s Missing From the Web Platform?

Overview of 975: What’s Missing From the Web Platform?

Hosts Wes Bos and Scott Tolinski discuss gaps they — and the web‑dev community — still feel exist in the web platform (HTML/CSS/JS, browsers, runtimes and APIs). They walk through UI primitives, JavaScript syntax proposals, desired platform APIs (Bluetooth, serial, sockets, NFC, cookie/consent, identity), CSS improvements, browser/runtime features (Node/Bun APIs) and how AI/model access might fit into browsers. The episode mixes practical frustrations, ongoing proposals, idealistic wishlist items, and suggestions for how platform evolution could better serve developers and users.

Key topics discussed

• Better, more usable HTML primitives (selects, toggles, tabs, file inputs, combo boxes, multi-selects).
• Language syntax desires: built‑in types (TypeScript or alternatives), pipe operator.
• Platform APIs: battery, cookie/consent management, identity, Bluetooth/serial, NFC, sockets, improved drag & drop.
• Browser & runtime features: content‑visibility/virtualization, better built‑in databases/sync (CRDTs), more HTTP verbs on forms (PUT/PATCH/DELETE), text metrics.
• AI in the browser: thoughtful, standard API that supports local & remote models; concerns about rushing immature APIs.
• Node/Bun runtime APIs: web speech (TTS/STT) and other higher‑level services.

Missing DOM / UI primitives

• Customizable select (already improving): allows fully styleable native dropdowns while retaining accessibility/keyboard behavior.
• Combo box / multi-select: filtering + multi tag selection are in progress and highly desired.
• Date picker: current native is poor; hosts doubt a one‑size‑fits‑all date picker will be sufficient due to complexity — better to have stylable primitives and let libs handle complex cases.
• Tabs: long overdue; should be a native primitive rather than hacks with details/accordion.
• File upload: native styling + easy image preview/resize would save lots of boilerplate.
• Toggles (native switch): Safari has it — Chrome/Firefox should add a stylable native option to avoid accessibility hacks.
• Drag & drop: native primitives exist but UX/behavior options are inconsistent — libraries still needed for full feature sets.

JavaScript syntax wishlist

• Type annotations / TypeScript in the language: strong consensus many treat TypeScript as default; proposals like "types as comments" exist but adoption/standard path is uncertain.
• Pipe operator: frequently requested for clearer function composition/flow; proposal has languished.
• General note: language changes must consider long‑term compatibility; progress is slow by design.

Desired Web APIs

• navigator.getBattery (example of a useful existing API) — good precedent for pragmatic, useful device APIs.
• Standard cookie consent / opt‑in APIs: single browser‑managed consent store so sites don’t spam users with banners and dark patterns.
• Identity: browser‑level login state / passkey integration to avoid reinventing auth on every site (complex & controversial).
• getElementByText: select elements by their inner text (useful for agentic tooling, tests, accessibility).
• Native reactive templating: lightweight primitives (signals/templates) so small apps can auto‑update DOM without full frameworks.
• Sync/CRDT primitives or standard sync protocol: an idealized local‑first/sync primitive (likely requires servers).
• Better built‑in client DBs: IndexedDB is low level; nicer, more ergonomic browser DB (or SQLite‑like standard) would help offline/local apps.
• Content visibility & virtualization: browser should do correct deferral of off‑screen rendering without breaking browser features like Command+F.
• Forms: support for PUT/PATCH/DELETE methods natively (currently only GET and POST).
• Text metrics: precise bounding box for characters (helpful for animations/typography).
• Bluetooth / Web Serial / NFC / raw sockets: powerful for hardware/UIs but inconsistent browser support (Safari/Firefox lagging).

CSS improvements

• Ability to define animation speed in physical units (pixels/second) rather than just duration, so animations feel consistent irrespective of distance.
• CSS strict mode: a way to opt out of legacy cruft (like how JS has "use strict") — could let new projects adopt a cleaner baseline (e.g., border-box as default).
• TextBox Trim (already helpful) and more typography/animation primitives.

Browser & engine considerations

• Many devs wish for a Chromium move by Safari (for ease), but hosts argue against a single engine: competition prevents stagnation and drives innovation.
• Debugging and platform inconsistencies (iOS Safari particularly) are pain points; better parity would help, but not at the cost of one‑engine dominance.

AI and model access in browsers

• Caution urged: don’t rush an AI API to match current web needs; unclear what a stable, useful standard API should look like.
• Host ideal: a single API that can use:
  • Local device models (private, faster, no cloud cost),
  • Developer‑supplied models (e.g., loaded via Transformers.js),
  • Remote hosted models (cloud).
• Use cases: natural‑language date inputs, input parsing/validation (postal codes, email trimming), developer tooling, instant interactive features.
• Practical reality: local models today can be slow/low‑quality; demos are interesting but not yet a full replacement for cloud models. Still, rapid progress suggests integrating model access thoughtfully is important.
• Text‑to‑speech and speech‑to‑text APIs: quality currently poor in native browser APIs — desire for high quality TTS/STT in both browsers and Node/Bun runtimes (and ability to use local or third‑party models).

Runtimes (Node, Bun, Deno) APIs

• Bring richer browser APIs to runtimes: e.g., web speech (TTS/STT), other higher‑level device APIs.
• The web speech API exists in browsers but is often low quality; having better runtime access (and pluggable models) would make server/local apps much more capable.

Notable quotes / insights

• “TypeScript is JavaScript at this point.” — reflects how entrenched TS is in developer workflows.
• “We do not want a single browser engine.” — argues that multiple engines are healthy for the web.
• The browser should provide primitives (accessibility, keyboard semantics) and let developers style/compose them rather than reimplementing behavior.

Practical recommendations / action items

• If you care about a feature, engage with standards groups (WICG/OpenUI/W3C), file bugs, and share use cases — standards folks pay attention to developer feedback.
• For immediate needs: rely on well‑maintained libraries for complex UI/drag/drop/sync; use progressive enhancement and accessibility primitives where possible.
• Experiment with local model tooling, but design fallbacks to cloud models while device inference matures.
• Advocate for better browser parity (test/use and report iOS/Safari bugs) and contribute to spec discussions if feasible.

Host picks

• Wes: Monarch (budgeting software) — improved goals, reporting and account/transaction tracking.
• Scott: Sloanic rechargeable headlamp — USB‑C, removable 18650 battery, durable and bright.

Bottom line

The web platform has improved massively, but there's a long wishlist of practical features (stylable UI primitives, better developer ergonomics in JS/CSS, richer device & sync APIs, thoughtful AI/model integration and higher‑quality runtime APIs). Many of the missing pieces are already being worked on or prototyped — participation and concrete use cases from developers will help prioritize what lands next.