Why don't more developers “use the platform”?

Original Article ↗ Hacker News Discussion ↗

Many web developers still favor React-style frameworks and custom widgets over native browser features, arguing that “the platform” is historically inconsistent, underpowered for real-world UX needs, and hard to work with directly. Examples like `<dialog>`, native date/time pickers, `<datalist>`, and Web Components are cited as buggy, inflexible or inaccessible across browsers, while design demands and product requirements frequently exceed what built-in controls can do. Others counter that modern HTML/CSS/JS have improved and can replace a lot of JavaScript-heavy tooling, but acknowledge that ecosystem momentum, documentation, and existing abstractions make it hard to shift back to browser primitives.

Perceived Limitations of Native Browser Features

  • Many native widgets (date/time inputs, <dialog>, <datalist>, multi-select, comboboxes) are seen as too limited or inflexible for real-world requirements (e.g., disabling arbitrary dates, searchable lists, weekday-only scheduling).
  • Native drag-and-drop and some form controls behave poorly or inconsistently across browsers and devices (iOS Safari, Firefox bugs, odd edge cases like “99 minutes” in time fields).
  • Developers often find they quickly “outgrow” native elements and end up re-implementing them in JS anyway.

Web Components vs Frameworks

  • Web Components are widely criticized as awkward, low-level, and hard to use directly (boilerplate, attributes vs properties, state management, Shadow DOM pain, styling/resets).
  • Many feel you effectively need a wrapper library like Lit or Stencil; at that point it feels similar to using React, just with different tradeoffs.
  • Others defend Web Components as performant building blocks, but acknowledge rough integration with the broader platform and lack of ergonomic APIs.

Developer Experience, History, and Ecosystem Effects

  • Historically the platform was weak; libraries from jQuery to React filled huge gaps and trained developers to reach for npm rather than specs.
  • React’s success is attributed less to pure technical superiority and more to superb documentation, teaching materials, conferences, and ecosystem momentum.
  • Once a technology wins mindshare, its community (examples, support, components) reinforces its dominance even if alternatives have some better properties.

Accessibility, UX, and Product Requirements

  • Teams often abandon native widgets because they can’t match UX/brand designs or accessibility expectations (focus management, keyboard behavior, screen readers).
  • Custom controls are frequently more broken on some devices, but designers and PMs still demand bespoke UI; engineers feel forced away from platform defaults.

Browser Inconsistencies and Platform Trust

  • Inconsistent or buggy implementations (especially Safari and older versions) make devs wary of relying on “the platform.”
  • Polyfills, workarounds, and long standards timelines incentivize solving problems in JS where teams have full control and can ship fixes immediately.

AI, Abstraction, and “Use the Platform”

  • Some use AI to generate mostly-native, JS-light sites; others note you still need deep platform knowledge to debug AI’s mistakes.
  • Several argue that HTML/CSS/DOM are effectively a low-level assembly; frameworks and reactive patterns are seen as the practical way to manage state and complexity.