Why Dioxus Should Avoid A Component Library In The Near Term

[mcmah309]

It seems the v0.7.0 milestone intends to add a "Component Library". Regarding this, one of the biggest mistakes Flutter made was to focus too much on components, such as Material and Cupertino, rather than building tools that allowed developers to more easily create custom experiences. What developers really wanted was these core tools and a solid development/deployment experience. Fortunately for Dioxus, HML/CSS/Tailwind/SVG/WGPU etc. already put Dioxus ahead in the ability to create custom experiences and there are many component libraries built on top of these tools. As Dioxus matures, I fully expect Dioxus specific component libraries to emerge naturally from the community. Dioxus Is also relatively new and likely to change in the future. Adding a component library would require developer resources in implementing/maintenance/migrations and draw resources away from core features. Flutter is fairly stable and half of their current issues are related to Material or Cupertino, I would hate for Dioxus to fall into this hole.

This said, I’m not sure a component library should be a part of Dioxus and make the same mistakes Flutter made with Material and Cupertino. If anything, they should a separate crate. But from a long time Flutter Developers perspective, I truly don’t think that Dioxus developer resources should be spent on building component libraries. Time would be better served focusing on the developers experience across platforms (bugs, native integrations, tools, docs) rather than a component library.

This all comes down to managing finite developer resources. Whatever direction is decided, I look forward to seeing Dioxus grow into the future!

References:

• Flutter issue to extract out Material and Cupertino: ☂️ Move the material and cupertino packages outside of Flutter flutter/flutter#101479
• Flutter Blank Canvas (initiative to allow developers to more easily create custom experiences): https://docs.google.com/document/d/1rS_RO2DQ_d4_roc3taAB6vXFjv7-9hJP7pyZ9NhPOdA/edit?resourcekey=0-VBzTPoqLwsruo0j9dokuOg&tab=t.0#heading=h.34a91yqebirw
• Flutter Material and Cupertino issues: https://github.com/flutter/flutter/issues?q=is%3Aopen%20(label%3A%22f%3A%20material%20design%22%20OR%20label%3A%22f%3A%20cupertino%22)

[Gaubee]

I have some additional points that might lead to different conclusions.

1. Flutter's official component library is not entirely a hindrance. I agree that Flutter's approach to implementing custom components can be problematic—sometimes I even have to modify Flutter's source code to achieve the desired effect. However, at least in mobile development, achieving a fully unified navigation standard within a canvas requires official effort. This ensures the quality of applications developed with Flutter to the greatest extent, providing a smooth experience even for beginners.

2. Dioxus provides a Native Renderer, which is a brand-new renderer and may come with a lot of instability. As you mentioned, Dioxus is also relatively new, so if the community were to directly build UI libraries targeting the Native Renderer, the Dioxus team might hesitate to make breaking changes at the core level. Providing a "Component Library Primitives" with a higher level of abstraction and standardization can help avoid this issue. I believe this is also the original intention behind this goal.

Therefore, I propose providing a "Component Library Primitives" that can not only give the community confidence to develop but also lower the barrier for beginners to achieve a smooth experience, while reducing the long-term costs of addressing compatibility issues.

[Gaubee]

After watching the official YouTube videos discussing "Component Library Primitives," I realized my initial understanding was slightly off-track. Regarding the second point I mentioned, it appears less about technical considerations for "Native Renderer" adaptation and more about establishing paradigms through practice. This approach is common in the industry—for example:

• The iced-rs team built the iced_aw component library
• The Angular team developed their Material component suite

My overall perspective remains positive. The official team's direct involvement in component library development naturally drives deeper insights into best practices, which will accelerate Dioxus's practical development.

[mcmah309]

Posting this here for posterity. Feel free to comment more.

List of currently supported dioxus specific community component libraries I know about:

General Components

• https://github.com/cbdefontenay/freyr
• https://github.com/42Angouleme/dioxus-tw-components
• https://github.com/bionic-gpt/daisy-rsx
• https://github.com/Plebshot/dioxus-daisy

Icons

• https://github.com/RustForWeb/lucide
• https://github.com/dioxus-community/dioxus-free-icons
• https://github.com/lennartkloock/dioxus-material-icons