- 1 for the CSS parts: basically a DSL to define a giant tree of Tailwind CSS class properties, with some conditionals to take care of the context (iOS vs. Material) and other optional features.
- 3 for the React/Vue/Svelte components. They seem to provide the same features, each implemented independently.
There is definitively a separation of concern between style and behavior, so the style part could be reused in other frameworks.
But there is also a "DRY" violation with the 3 independently developed framework-dependent parts. Could this be improved by having a framework-independent part (you suggest Web Components, what would be the easier way to get this part done?) and framework-dependent adapter, or would this extra layer of indirection make things harder to understand?
Really curious about this. Can you link to some context?
We're looking to find the lowest common denominator of expressing UI components and thinking about JSON metadata instead of Web Components. With this, we'd have to implement some adaptor that maps JSON to each UI library, but in our case we really only have to worry about React and Native Mobile.
> Most people who use React don’t use Web Components, but you may want to, especially if you are using third-party UI components that are written using Web Components.
So it seems like this would be exactly the kind of use case where using web components would be ok.
Looking through the source code, they reimplemented all components for react, Vue and svelte. That's an impressive amount of work.
What confuses me is why they would do that... Why not just use Web Components as the core?
If you want clean integration with a framework, a small "glue" wrapper component should be easy.
I question whether the current development approach is maintainable.