Have you ever been faced with the decision of whether to use ready-made UI components or create your own solution? I recently dealt with such a situation and wanted to share my experiences. Through this material, I wanted to convey my thoughts that accompanied me during the decision-making process.

🧳 Libraries

What are libraries exactly? In a few words, they are simply a collection of solutions and best practices designed to speed up your work and address recurring requirements, such as faster creation of new projects, component reusability, and function reusability. Nowadays, we want to do as much as possible, as quickly as possible, and as efficiently as possible.

So why would creating your own library be beneficial? Why not use something ready-made? After all, the market offers a wide range of solutions that provide a variety of UI components, allowing for a faster start to a new project. Some of these solutions include Vuetify, PrimeVue, and MUI.

🙋 Questions we asked ourselves

Initially, we need to answer several important business questions.

1. Do we want our application design to be unique and not replicate what free solutions offer?
   Definitely yes! As a company, we want to be unique and stand out in the market not only in terms of the solutions we provide but also in terms of having a unique application design that is associated with our brand.

2. Do we have experienced developers and the time to create such a solution?
   This is a highly debatable issue because even with experienced developers, there is always a shortage of time since, apart from building a library, we also need to develop existing products. However, we decided to try to allocate time to start the work and intensify it from the very beginning.

3. How responsive do we want to be to what is happening in the market at any given moment?
   Based on our experience with ready-made tools and large projects we undertake for multiple clients, we realized that we want to be highly responsive in the market and be able to react quickly to changes happening around us.

Implementing a custom UI library is usually a lengthy and demanding process, which involves a certain level of complexity. Creating custom components is time-consuming, error-prone, and requires solid technical and substantive knowledge.

I once faced this decision myself, precisely two years ago. We had several applications using ready-made libraries. At that time and considering the scale of our projects, the ready-made solutions proved to be completely inadequate. To the point that they hindered our project development. We made the decision to create our own UI component library using Vue.js. Before starting the development, our team and I tried to analyze all the pros and cons together.

Arguments in favor:

1. Speed of keeping up with changes and addressing business needs:
   By having our own implemented solution, we can quickly adapt to changes made by the business, such as modifications in component appearance, behavior, color schemes, and interfaces.
2. Performance and library size:
   Creating a custom solution allows us to avoid unnecessary dependencies that often come with ready-made solutions, which can slow down our library and significantly increase its size.
3. Creating only necessary components:
   There’s no need to create a whole package of 200 components. It is enough to develop the ones that are most important for our current needs, and new components can always be added later.
4. Bugs in ready-made UI solutions:
   Bugs in existing UI solutions may affect us more than the broader community. Waiting for a solution to our specific problem can be time-consuming (even months). In such cases, forking the library and making our own fixes becomes a viable option.
5. Library and source code control:
   This is one of the significant advantages. Having control over our source code allows us to access it at any time and make necessary code corrections when needed. Additionally, we only use the dependencies that are required.

Arguments against:

1. Requires dedicated resources and maintenance:
   The company needs someone responsible for managing and maintaining the library, which increases costs for the organization.
2. Potentially more errors and fewer components:
   Developing a custom solution may introduce more errors, and initially, there might be a smaller number of components compared to ready-made solutions.
3. Longer development time:
   Creating such a solution takes a considerable amount of time.
4. High entry barrier:
   Considerable technical knowledge is required to ensure the developed solution will not be discarded in a few months.
5. Additional effort for adding new components:
   Compared to ready-made solutions that provide components out of the box, adding new components to a custom library requires extra work.

🔥 Choice of solution

After conducting a technical analysis, we concluded that creating our own component library was the best choice. I started reading about how to create a custom component library using Vue (at that time, version 2) (rollup + webpack). Most online resources only provided simple and basic usage examples, so our team had to figure out many functionalities, optimizations, and other processes on our own. The Discord channel became a valuable resource where I received helpful advice and best practices from the Vue community. However, there were moments of frustration when a whole day of research yielded no meaningful lines of code. It’s a relatable feeling, isn’t it?

The process of component creation began, starting with what seemed like a simple task: creating a select component. However, it turned out to be more complex than anticipated. To this day, I remember the words of Tomasz Jakut (Comandeer) from a forum, paraphrasing: “I have yet to see a correct implementation of a fully accessible custom select component.” He was absolutely right. Writing components with proper accessibility is challenging, but it’s also a rewarding and exciting experience. Creating a component library provides an opportunity to learn and grow, from implementing a basic button to more advanced optimization mechanisms, tree shaking, and A11Y considerations.

🧨 Arrival of Vue 3

The second version of our library was performing well. However, Vue released version 3 and there was no straightforward way to migrate. After days of searching for solutions, browsing numerous web pages, reading about similar issues on GitHub, and directly contacting the Vue community on Discord, we reached the conclusion that the best approach would be:

1. Copying Vue 2 components
2. Transferring them to a new repository
3. Setting up the project again using Vite
4. Bringing everything together through manual code adjustments and migrations

The process took about two weeks for a senior developer. What did we discover? We likely had one of the fastest component library migrations in the market. Just a month after Vue 3 was released, we were already using the new Vue version and Vite, with functioning components. Additionally, we heavily focused on documenting our components and made an unconventional choice at the time by opting for Histoire instead of the popular Storybook.

Furthermore, creating components in Figma and a complete Design System proved to be a great decision. This allowed our library to mirror the component library in Figma, enabling rapid prototyping and seamless implementation into projects.

🪄 Summary

Was it worth it? Absolutely! We’re not perfect, as there are instances where bugs need fixing or new components need to be added. However, our library remains stable. We have a comprehensive set of UI components that we continuously develop and utilize in various contexts. We prioritize accessibility (A11Y) and provide thorough documentation, ensuring adaptability to market changes.

This experience taught us the importance of conducting detailed technical analyses before making any decisions. With proper analysis, there is a greater chance of selecting the most suitable solution for your needs.