Do not build your in-house web component library
How many button components do we need to build in our lifetime?
In any complex web application project, the idea of building an in-house design system and component library almost always comes up. While I am a huge fan of design systems, creating an in-house web component library is another story. It’s a time-sink. Every. Single. Time.
Why do design systems and web component libraries matter?
Before we dive into why building an in-house web component library is a mistake, let’s clarify what design systems and web component libraries are and why they matter.
Design Systems
Design systems are a way of organizing your UI designs into reusable components. You start at the most basic level: colors, fonts, inputs, and buttons. Then compose those into more complex components: search bars, menus, and hero units. We then compose these into headers, search results, and content areas. Finally, we combine everything into full-page templates.
Web component libraries
Web component libraries are the developer’s toolkit. In the library, we turn our designs into reusable, functional components ready for our applications. We can compose these into the higher-level components and full-page templates needed for our customer experience.
Why should we do this?
The benefits of using a design system and web components are plentiful. A consistent design system ensures that buttons, inputs, and menus look and behave the same across your application, reducing user confusion and boosting trust. For developers, reusable components mean faster implementation and fewer bugs.
Everybody wins. Right?
Everybody does unless you make this mistake…
Do not build your in-house web component library
Building your in-house web component library takes a very long time. We always underestimate the time it takes to build out the lower-level components. It takes forever to get the basics right.
Form Elements
Let’s take a look at form elements. The list of things we need to think about is quite extensive. Have a look at some of these considerations:
Form validation
Accessibility
Special language characters
Right-to-left languages
Mobile inputs vs desktop inputs
We need a date-picker!
Buttons
Even something as seemingly simple as a button can quickly spiral into complexity: different styles (Primary, Secondary, Warning), sizes (Small, Large), states (Loading, Disabled), and variations with icons. Multiply this across your app, and it becomes clear how much effort is required.
Maintainability
All these variations and quality-of-life requirements take a long time to get down correctly. Good documentation, meaningful tests, and keeping everything secure and accessible. It takes a lot of effort to build this properly. You can’t skip any of it unless you want to end up with a maintenance nightmare.
Adopt a Library
Instead of reinventing the wheel, leverage existing libraries built by teams who already solved these common challenges. This approach saves time and ensures you build on a foundation of tested and optimized components.
Adopt a library and save yourself months of work creating your base components. You immediately free yourself up to create valuable experiences for your customers. Let others build the basics, you focus on what makes your experience unique.
Not invented here
Some people will complain if you suggest this route:
“We will be in trouble when their components don’t work like we need them to”
Of course, this can happen, especially if you are building something complex. When this happens:
Accept the limitations and work around them;
Extend their component and contribute back if it’s open-source;
Build your custom component, exactly the way you need it
“What if they stop maintaining their library?”
Indeed, libraries may eventually lose active maintenance. But this risk isn’t unique to third-party solutions. Homegrown libraries face the same challenges when original developers move on to other projects. Often lacking proper documentation and tests to ensure future maintainability.
At least with a properly documented open-source project you can fork it and continue maintaining it yourself.
Which libraries to use
Shoelace (soon to be Web Awesome) and shadcn/ui are exciting libraries to check out, or a quick search will provide many other great options. Each library fits specific use cases better or worse.
Shoelace is great for teams seeking a robust, pre-built solution that works seamlessly across frameworks. Shadcn/ui, on the other hand, is ideal for teams who need maximum customization and are comfortable working directly with source code.
Shoelace
Shoelace offers a huge set of web components. The documentation is great. It is super easy to install and use on a web project, or using frameworks like Angular, React, and Vue.
Web Awesome will replace Shoelace soon. But at the time of writing Web Awesome is still in alpha.
Shadcn/ui
This library takes a different approach than normal libraries. Instead of installing the components using a package manager, you grab the components’ source code and add it to your projects. After which you are free to customize as you see fit.
Make the smart choice
Don’t let your team get bogged down in reinventing the wheel. Proven component libraries allow you to focus your time and energy on what truly matters: delivering value to your customers. Start building smarter today.
Have you experienced building in-house design systems, or adopted existing ones? Let me know in the comments.