Component library choices (Ant, MaterialUI, DaisyUI, ChakraUI)

[timclifford]

Following on from this issue #107 on which component library to use, we thought it would be good to extend this to an open poll for everyone to have their say.

We are looking for a library that:

• Works with React
• Has many "ready-to-use' components OTB
• Good integration with the current UI
• Cross-browser compatibly support

If there are others you suggest that are not in the list, then please add them in the comments.

[DaveDarsa]

I'm mostly leaning towards antd, we've also discussed it quite a bit - easy to adapt to and "lagoonify" with upcoming designs

[bomoko]

Keen to hear what others think.

[tobybellwood]

(apologies for recreating the poll - but I wanted to add links to the Design systems 🤕

[seanhamlin]

I personally do not mind what framework is used, I am just excited there will be a framework!

[stewest]

We've used MaterialUI (better) and Bootstrap (ok)... any chance of TailwindUI? https://tailwindui.com/ << this would be my choice if it were one! ;-)

[AlexSkrypnyk]

Hi all

When choosing a design system, especially for an open-source project, one should consider the following:

1. Community Support & Longevity: Is design system widely known and easy to maintain? Does the community know how to use it?
2. Extensibility: how easy it is to create new components based on the existing components (to avoid breaking the design patterns).
3. Graphical assets: does the design system provide a graphical UI kit with all components available to be able to create design mockups? Some design systems provide Figma templates which can be used to easily bootstrap designs.
4. Accessibility, browser support, technical stack, modularity, performance - all of these are important as well.

And I want to point out the difference between a design system and a components kit.

Something like https://tailwindui.com/ is a components kit and not a design system. What this means is that you may use the components as needed, but there is no consistent systematic approach of using them (just look at all of the inline code which is not systematic). You may end up with a large maintenance burden of extensively customised components that would look different.

I would suggest to come up with a cons/pros list to assess each of these to have a clear understanding before making a final choice.

There is also a case for the actual visual part: Lagoon UI is not a flashy marketing site but rather a heavily used operation dashboard, so using frameworks like Material UI, which is used in apps like Gmail and Google Docs (which are about productivity rather than visuals), would be a good choice as users already used to similar interfaces. There are already so many systems in the daily use of the IT operations, and each of them trying to standout with a custom design where the functional design would suffice.