Land Technologies
< all posts

Component Libraries

Posted by Dave N on April 29, 2021 · 6 min read reactfrontenddecisions

In the last post I discussed the three main CSS techniques: Classical CSS, Utility-First CSS and CSS-in-JS. Now I want to take a look at some of the most popular and interesting component libraries out there to get some inspiration and see if any could be usable as a base for our own.

Component Library

What makes a great component library?

When looking at Component Libraries there are several things that are important to us:

  • Github Stars - Although not a perfect metric, Github stars give an indication of how popular a project is. Without an active community, traction can be lost, and the release of bug fixes and new features can slow down or stop completely.

Github Star

  • Commits - As above, it’s important that a project stays active. Looking at the Insights section of a projects Github repo can be really useful to determine the number of commits, merged pull requests and fixed issues, as well as the code frequency over a projects’ lifetime, and the number of contributors. In this case the number of commits made to the project over the last 30 days gives a rough idea of how actively maintained a project is.
  • Bundle Size - It’s important not to add a huge dependencies, as load times and performance will quickly start to deteriorate. Depending on how you use it, the import cost is usually much lower so use these numbers as caution and test it out yourself.

Node Modules

  • Tree Shakable - This lets you import individual components rather than the entire library, dramatically reducing the imported bundle size. Watch out for libraries with a large bundle size that don’t support tree shaking.
  • Range of Components - If a component library doesn’t have enough components, you either have to adopt a second or even more libraries, or you have to create your own. Having multiple libraries will add inconsistency and increase bundle size, and if you end up writing most of your own components you’d likely be better not being tied to a project that might change direction in the future. However, in some cases having a few well-thought-out base components that you can extend can save a lot of time.

Everybody Components

  • Mobile Support - We’ve decided to build mobile-first, rather than supporting separate applications for both mobile and desktop, so having mobile support is important.
  • Accessibility Focus - Getting accessibility right can be a lot of work and is often an afterthought, so having a library that has focused on adding accessibility support can save a lot of time in the long run.
  • Themeable - As we’re going to use our own design system it’s critical that we’re able to easily theme components to match without having to fight overwriting existing styles.
  • Unstyled - Similar to above, having full control over the styling library we use, and the visual design of components makes apply a design system much easier.
  • TypeScript - We are big fans TypeScript, so having a library that is written in TypeScript, or at least has type definitions, makes development for us a much nicer experience.

TypeScript

  • Detailed Docs - Having worked with libraries with bad or missing documentation in the past, it can be a real nightmare. TypeScript already provides a decent level of documentation, but having code examples and explanations for the API can be priceless.

Bad Docs

  • SSR Support - Sever side rendering offers significantly better performance for most users, so it’s important that the component library used doesn’t prevent this.

The Great Component Library Review

Below are the results from the top 20 libraries reviewed.

Component Libraries Compared

Some key takeaways from this research based on our needs:

  • Tailwind is currently the most popular Utility-First solution with over 40k Github stars. Headless UI looks like it would provide a perfect base to a component library, but it is still early in development (part way through writing v1 just released) and has a limited number of components. Tailwind UI seems to provide a large number of examples that could be paired with Headless UI or potentially another offering, but it is hard to tell as it’s not open source.
  • Having reviewed a number of CSS-in-JS options, Styled System seems best suited for building a component library, and works nicely with other solutions like Styled Components and Emotion when used in applications. Theme UI looks like the best extension of it, with the only real downside being its lower level of popularity compared to other solutions. It does come partially styled, but can be easily updated using CSS-in-JS and even has support for Tailwind.
  • Although Bootstrap can sometimes get some bad press from developers (I personally have a lot of experience ripping it out of projects where it’s been used badly) for our needs it seems to tick most of the boxes and is the best Classical CSS solution.
  • As we have our own design system Material UI isn’t really an option as it’s styling is heavily opinionated and difficult to change. However, if this wasn’t the case it would easily be one of the top options.
  • RadixUI looks really interesting, having a Primitives repo that contains completely super lightweight unstyled components, and a Design System repo showing how it can be paired with a styling library to create a fully featured component library. The main concern with the project is that it’s currently less than a year old and so far has a fairly low following.

Roundup

We have some time coming up to trial different libraries to ensure they’re able to meet our requirements, and to ensure we don’t regret diving all into to one solution without having tested alternatives. We’ve used some of the same tech for over 5 years so it could turn out to be a longterm commitment. Based on the findings above these are the current candidates to trial:

  • Headless UI components, styled with Tailwind, using Tailwind UI as reference
  • Radix UI components, styled with Tailwind
  • Styled System or Theme UI components, styled with either Styled Components or Tailwind
  • Build our own components from scratch, styled with Tailwind

Pick One

The first couple of options are the most risky as they rely on newer, less established components libraries. However, the components come unstyled meaning we shouldn’t run into any conflicts with our design system down the line. Pairing either with Tailwind should allow us to style at pace and keep our code complexity down, so they have the most potential!

Using Styled System or Theme UI is a safer solution as they are much more established libraries. Pairing these with Styled Components would offer a lot of power to achieve pixel perfect designs. The main downside is the potential for a lot of complexity compared to the first couple of solutions, which could slow us down later down the line.

Finally, there’s the option we look to build our own components. Building from scratch would mostly likely prove too time-consuming, so starting with an existing library, like Headless UI or Radix, then gradually swapping in our own components when needed is a more realistic approach. We need to review how easy this approach would be and if any libraries could make this difficult.


reactfrontenddecisions
Land Technologies

We are the engineers behind LandInsight and LandEnhance. We’re helping property professionals build more houses, one line of code at a time. We're a remote-first company with our tech team in Europe, and yes, we're hiring!

© 2021, Built with Gatsby
LAND TECHNOLOGIES LTD, m: WeWork c/o LandTech, 10 Devonshire Square, London, EC2M 4PL t: 0203 086 7855
© 2016 Land Technologies Ltd. Registered Company Number 08845300.