There are technical reasons for not supporting arbitrary design systems. Here are the major ones:
- Design systems are different and contain different primitives - they use different CSS classes to convey certain things (button styling, paddings etc). This alone would require X different rendering implementations for Y components. I know there are vendors who use that approach but we can't afford the sheer effort required to support X different rendering implementations on top of the existing one.
- Design systems lack styling / primitives for certain UI components (Scheduler, Chart, Gauge are the first that come to mind). Or in some cases they have the basis (a Table) but don't have the complex features (DataGrid with grouping, hierarchy etc).
In this context our response remains the same - we don't plan to provide rendering implementations based on a specific design system.
We are doing something different instead - provide themes that match the UX of a design system instead of using its CSS implementation. For example we already have a Material and Fluent themes. They are using the existing Radzen CSS classes though. We may also add themes that look like Tailwind, Bulma or whatever the current modern design system is. It would again be using the Radzen CSS classes and won't be customizable as a regular Tailwind theme for example (via custom build). This is the approach that most (all?) commercial component vendors have adopted and it has proven to be a reasonable compromise.