Component Library Evaluation
- Jonas Bergmeier
- Priit Puru
Work in Progress
The sandbox UI has to be built up ambitiously in terms of time as a vertical prototype. This requires the use of a broad-based component library anyway - a decision must be made for this. This decision will be shared with the committees and working groups and may persist beyond the sandbox due to structured decision making. This should be made as data-based as possible: Which framework scores best in the following areas?
Performance
maintenance
Accessibility
Licensing
Breadth and depth of components
The following table is used to evaluate these factors:
Library | Performance | P | Maintenance (Github activity) | M | Accessibility OOB | A | License | Internationalization OOB | Comment |
|---|---|---|---|---|---|---|---|---|---|
490kB MINIFIED 135.4kB MINIFIED + GZIPPED + ~13kB dependencies |
| 82.7k stars 1.4k watching 28.5k forks 1.1k open issues |
| unclear ([material-ui][docs] Create ADA compliance documentation · Issue #14187 · mui/material-ui ) |
| base is open-source, MIT some things open-core, paid | Seems to have great localization out of the box, not a problem to add your own i18n systems | OOB styling a lot of talent that has experience in it + material design system pretty well known | |
265kB MINIFIED 73.7kB MINIFIED + GZIPPED + styles 270.4kB MINIFIED 68.1 kB MINIFIED + GZIPPED |
| 12.9k stars 221 watching 4k forks 156 open issues |
|
| MIT | Not a problem, doesn’t come with much built-in text |
| ||
114.2kB MINIFIED 36.9kB MINIFIED + GZIPPED + bootstrap if customizing 58.9kB MINIFIED 15.6kB MINIFIED + GZIPPED |
| 21.3k stars 431 watching 3.4k forks 142 open issues + bootstrap itself 160k stars 6.9k watching 77.6k forks 255 open issues |
| bootstrap itself is pretty generic and can be used to hit any necessary accesibility goal react-bootstrap doesn’t seem to have many tickets open pertaining to accessibility (around 5 with the “accessibility” tag on github) most likely fine |
| MIT | Not a problem, doesn’t come with much built-in text | old (in a good way) a lot of talent out there that has experience with it | |
136.2kB MINIFIED 36kB MINIFIED + GZIPPED |
| 6.3k stars 56 watching 341 forks 47 open issues |
| Ariakit seems to be built on the basis of having good accessibility, but still in alpha |
| MIT | Not a problem, doesn’t come with much built-in text | Reakit deprecated? now is Ariakit - documentation not ready, breaking changes until official release | |
→ chosen | 379.4kB MINIFIED 113.1kB MINIFIED + GZIPPED |
| 29.8k stars 206 watching 2.7k forks 88 open issues |
| Accessibility has been taken into account and at least the basics seem to be there |
| MIT | Not a problem, doesn’t come with much built-in text | premium version? (how does this affect dev flow in the future?) OOB styling, but easily customizable comes with CSS-in-JS |
Performance currently filled with data from bundlephobia.com. Size can be a good indication of how many included components there are, but not the total load when installed - most/all modern kits are treeshakable (only code used is shipped to the user)
Questions from Priit:
Is this a forever-decision?
Plans of building a UI kit in the future?
What ramifications are there to locking in a choice now?
Meeting notes Nov 17, 2022 @Priit Puru @Artun Gürkan @Jonas Bergmeier
it’s a concept/prototype - we will keep it as lean as possible to be fast
sandbox implementation should not hinder added value to component library and general workflows in the future, i.e. usage of Storybook or custom components etc.
if possible we want to stick with component library of choice OOB
only skinning on top of the library would add value to the sandbox and not customize the core of the library