Should Web Components Play a Larger Role in Cross-Platform Design Systems?

[mbuckley]

I have a question about GitHub's approach to component JavaScript implementation. I understand that you use web components/catalyst wrapped with a ViewComponent when JavaScript interactivity is required (such as for autocomplete functionality). I'm wondering: do you still believe that the component library should export ViewComponents as the primary interface, or have your thoughts evolved regarding web components playing a larger role and being used directly by consuming applications?

For context, we have several applications that don't use Ruby on Rails, which has us reconsidering how to provide our design system components to these applications. We're exploring two main options:

1. Reimplement the component specifications in a different technology, like React
2. Build universal web components (like <auto-complete />) that could be used across all our applications directly

My main concern with fully embracing web components is that we might lose the benefits that Ruby/React-first development provides.

[joelhawksley]

My main concern with fully embracing web components is that we might lose the benefits that Ruby/React-first development provides.

That's what we've seen in practice, especially as React's support for Web Components has been sub-optimal up until v19. In general, my experience has taught me that any time you try to build a cross-platform implementation you make significant sacrifices with regards to how much of each platform you can leverage. This is especially true when considering bridging Ruby and Typescript stacks, which have fundamentally different runtime targets and numerous technical and philosophical differences.

My advice would be to standardize, at a minimum, on a shared set of accessibility-first integration tests for components implemented in both stacks. That gives you the flexibility to change how much code is shared between implementations on a case-by-case basis.

[mbuckley]

Thanks for the reply! I really like the idea of a shared set of accessible integration tests across both stacks and thinking about this more on a case by case basis vs a blanket solution. That approach feels more flexible and easier to change as the system evolves.