Custom vs Third-Party Component Libraries

In the early stages of a codebase lifecycle, creating a centralized component library for common components becomes common sense. This makes both appearance and behavior consistent across the entire application, while significantly reducing boilerplate code.

To create it, we have three options.

Third-Party Components Libraries

There are plenty of third-party libraries to choose from. They offer pre-built, reusable components that can accelerate the development process. These libraries are often well-documented and maintained by a large community of contributors.

Picking one of the most popular according to the framework of your choice is considered a safe option.

React

Vue

Angular

Svelte

Unfortunately, my experience with ready-made component libraries so far was not the best. Breaking changes, migrations and memory leaks are often time-consuming and I tend to believe most of them work until they don’t. Building a custom solution is another option.

Custom Component Libraries

Building your own component library sounds hard but in reality, is even harder. To do it correctly you need to account for different screen sizes, mobile-specific quirks, accessibility, component interactions and many more. But still, if you are working in a large company investing the time to build a component tailor-made to your needs might be worth the effort. You can see an example of how to tackle custom component implementation in this article about creating a reusable modal component in vue or how to build a component library in react.

Hybrid Solution

There is a third option that lies somewhere between. That’s creating a custom component built on top of a headless component library. A headless library is a collection of components with functionality but without styling. You need to configure the library and style it according to your branding before start using it.

The two most popular headless component libraries are:

For example, we can create a modal using Radix UI with the following code:

<script setup>
import { ref } from "vue";
import {
  DialogRoot,
  DialogTrigger,
  DialogContent,
  DialogOverlay,
  DialogPortal,
  DialogTitle,
  DialogDescription,
  DialogClose,
} from "radix-vue";

const open = ref(false);
</script>

<template>
  <DialogRoot v-model:open="open">
    <DialogTrigger>Open</DialogTrigger>
    <DialogPortal>
      <DialogOverlay />
      <DialogContent>
        <DialogTitle>Title</DialogTitle>
        <DialogDescription>Description</DialogDescription>
        <DialogClose>Close</DialogClose>
      </DialogContent>
    </DialogPortal>
  </DialogRoot>
</template>

The result is:

Custom vs Third-Party Component Libraries

The next step is to add classes that will be targeted with styles and make it look nice. You can see a step-by-step guide in the following article:

Radix-Vue: The Next Generation Component Library for Vue

Conclusion

Finding the balance between flexibility and rapid development is challenging. Third-party solutions are excellent for prototyping but can become problematic as a codebase grows larger. On the other hand, a custom implementation requires a significant investment of time, which is a valuable resource. Leveraging a headless component library makes the most sense nowadays. They provide a battle-tested solution focused on flexibility, maintainability and accessibility.

Custom vs Third-Party Component Libraries