Web Components interoperability

Slap yourself if

You think Web Components are framework-agnostic in practice or believe standards guarantee seamless interoperability.

Why this exists

Because teams adopt Web Components to escape framework lock-in and discover a new class of integration bugs caused by mismatched assumptions about events, props, styling, and lifecycles.

Mental model

Interoperability is not automatic. Web Components define low-level contracts that frameworks partially honor, adapt, or violate. Every boundary needs translation.

  • Frameworks wrap custom elements with adapters or heuristics.
  • Props, attributes, and events are bridged imperfectly.
  • Change detection and reactivity models diverge at the boundary.
  • Styling and theming require explicit contracts to cross encapsulation.
  • Passing complex data through attributes instead of properties.
  • Relying on event bubbling without composed events.
  • Expecting framework reactivity to track internal state changes.
  • Assuming CSS-in-JS can style shadow content.

Web Components interoperate at the DOM level, but frameworks impose adapters that change how properties, events, and updates flow across the boundary.

  • Claims full framework agnosticism.
  • Says 'it just works everywhere'.
  • Ignores event composition.
  • Treats attributes and properties as interchangeable.

Deep dive

Requires Pro

Premium deep dives include more internals, more scars.

The hidden adapter every framework inserts

Why events disappear across framework boundaries

Attributes, properties, and the cost of clarity

When Shadow DOM breaks integration expectations

How interoperability answers reveal experience gaps