Web Component Framework Research Journal

2026-07-22 11:00-11:20 ET

• Located the governing prompt in prompts/Visual-Engineering-Web-Component-Framework-Research-and-Handoff-Prompt.md.
• Confirmed repository reality:
  • Research repository, not a JavaScript workspace.
  • No package.json, lockfile, TypeScript config, workflow files, or component source packages are present.
  • Runtime tools available locally: Node v25.6.0, npm 11.8.0, Python 3.14.3.
• Read repository governance and metadata guidance:
  • content/projects/composition-science/canonical/composition-science-repository-governance-specification-v1.md
  • knowledge-platform/repository-architecture.md
  • knowledge-platform/metadata-standard.md
• Repository constraint revised:
  • Initial assumption: this repository might already contain component experiments or build infrastructure.
  • Updated finding: this repository mainly contains research artifacts and generated architecture notes, so implementation decisions belong in a future dedicated Web Components repository, not here.

2026-07-22 11:20-11:45 ET

• Read prior Design Library artifacts:
  • component-library-foundations-research-report.md
  • 2026-07-21-semantic-durability-research-execution-package.md
• Adopted previous high-confidence findings as starting hypotheses rather than conclusions:
  • Native controls should remain default.
  • Shadow DOM should be selective, not universal.
  • Layout primitives should be CSS-first.
  • Token architecture is a dependency model, not a styling dump.
• Added new mission-specific hypotheses about:
  • Custom Elements Manifest as canonical machine-readable API.
  • Framework wrappers as generated adapters.
  • Monorepo package structure.
  • Storybook and Playwright as documentation and test defaults.

2026-07-22 11:45-12:35 ET

• Collected current primary-source evidence from:
  • WHATWG HTML custom elements
  • MDN custom elements, Shadow DOM, ElementInternals, adoptedStyleSheets, container queries, CSS shadow parts
  • WICG scoped custom element registries proposal
  • Design Tokens Community Group and W3C group pages
  • Lit documentation
  • React 19 custom elements support notes
  • Vue Web Components documentation
  • Storybook framework support documentation
  • Playwright component-testing documentation
  • Open UI charter and working mode
• Major evidence shifts:
  • Scoped custom element registries remain proposal-stage, not an acceptable foundation assumption.
  • Form-associated custom elements are materially more viable than in earlier browser eras, but still require deliberate browser-matrix scoping and fallback rules.
  • React interoperability improved materially in React 19, weakening the case for mandatory React wrappers for every component.
  • Lit SSR remains available but still carries experimental/labs framing, so SSR should be validated with fixtures before becoming a framework-wide promise.

2026-07-22 12:35-13:05 ET

• Performed source-backed architecture probes rather than executable multi-framework probes.
• Limitation recorded:
  • Because the Visual Engineering repository has no JS workspace and the shell environment is network-restricted, installing and executing Lit/React/Vue fixture projects inside this repository was not justified.
  • Therefore, runtime framework probes remain implementation-phase work for the dedicated Web Components repository.
• Despite that limitation, enough evidence exists to decide foundational architecture because:
  • The repository’s current need is research and handoff, not package publishing.
  • High-impact conclusions are supported by multiple independent primary sources plus prior local research.

2026-07-22 13:05-13:35 ET

• Reached diminishing-returns threshold for this repository phase:
  • No unresolved foundation decision remained that would block repository creation.
  • Remaining unknowns are implementation-scoped: exact package names, exact browser/AT matrix, SSR integration choice, and pilot component ergonomics.
  • Additional cycles in this repository would likely duplicate evidence rather than reduce core architectural uncertainty.
• Final research position:
  • Use native Web Components as the smallest shared interoperability boundary for selected categories.
  • Do not turn every reusable UI artifact into a custom element.
  • Use a mixed architecture:
    • native HTML and CSS recipes by default,
    • Light DOM custom elements for content-rich composites and open styling needs,
    • Shadow DOM for bounded interactive widgets,
    • optional Lit-based authoring for complex interactive components,
    • framework adapters only where the consumer ergonomics justify them.