Why you should use open-source component libraries in your Design System

You can write your component library from scratch. But keep in mind that it's an expensive exercise.

Instead, you can use an open-source component library as core to your design system component library and benefit from the most common patterns.

Use it internally, don't expose it

We recommend not to expose the open-source library through your Design System.

Your component library should use the 3rd-party component library internally and only expose the API you want for your design system.

Embedding the 3rd-party library lets you replace it internally without impacting users of the design system. Additionally, it enables you to use other libraries internally with heterogeneous APIs and expose a homogenous API from your Design System.

Example: The Button

The most atomic element in a Design System.

Many open-source component libraries will come with extensive options to style buttons individually. You can change background colors, borders, or icons left/right... to name a few.

Pseudo code of what it looks like:

<Button bg="blue" border="darkblue" icon-left={<Icon value="check"/>}>OK</Button>
<Button bg="transparent" border="darkblue">Cancel</Button>

But that's not what you want to expose in your Design System - you want to expose more semantical meaning that can encapsulate all the details.

<Button variant="primary" icon="check">OK</Button>
<Button variant="secondary">Cancel</Button>

All the details are encapsulated in your Design System, and only the intent of use is exposed.

What do you get with open-source component libraries?

Accessibility

Creating accessible control components, as defined in WAI-ARIA Authoring Practices, is one the most challenging aspect of building a component library for the web.

Selecting an accessible component library is a must. Don't use a component library if it's not providing accessibility primitives.

See our curated list of accessible component libraries.

Quality

Open-source component libraries are used by multiple teams on multiple products. You have more production usage, which usually leads to higher overall quality.

It's like having a bigger team

If you build your component library from scratch, only the people in your organization can answer questions or fix bugs. If you are a massive organization like Google or IBM then it's probably not an issue.

Using an open-source component library gives you potential access to all teams also using this component library.

Which one to use?

Devon Govett answered this question over a thread in X (previously Twitter).

This is what he looks for:

Interactions:

  • Works with mouse, touch, and keyboard input
  • Hover, active, and focus states as appropriate for device
  • Predictable focus management
  • Adapt UI and behavior for input type

Accessibility:

  • Usable (tested) with multiple screen readers on various devices (e.g. mobile/desktop)
  • Accessible color contrast
  • Light/dark/high contrast modes
  • Reduced motion support for any animations
  • Responsive – support for small and large screens, 400% zoom

Internationalization:

  • International dates, numbers, collation, etc.
  • Localized strings, or the ability to provide them
  • Right-to-left layout support
  • Culturally appropriate use of color and icons
  • Avoid locale-specific assumptions

We established our favorite list of open-source components libraries for your Design System.

Building your design system?

Backlight is an all-in-one design system platform that makes it easy for the whole team to collaborate on, build and ship a design system.

Try for free