Building Future Proof Component Libraries
Why investing in flexibility today can lead to scalable success tomorrow.
Component libraries have become essential for ensuring consistency, scalability, and efficiency across applications. They allow engineers to reuse UI components, saving time and ensuring that design patterns and user experiences remain consistent across different parts of an application or multiple applications. However, when building a component library, one of your key decisions is to create the library using web components or tie it to your app's JavaScript framework. Each approach has pros and cons.
Web Components
Web components are a set of web platform APIs that allow you to create reusable and encapsulated custom elements. These elements can be used natively across the web and with different JavaScript frameworks.
Pros of Using Web Components
Framework agnostic - Web components are not tied to any specific JavaScript framework, making them highly versatile. You can use the same components in React, Angular, Vue, or even vanilla JavaScript applications. This makes them an excellent choice for organizations with multiple applications built with different frameworks.
Encapsulation - Web components encapsulate their styles and behaviors, ensuring they don’t interfere with the rest of your application. This leads to fewer CSS and JavaScript conflicts, allowing you to maintain a clean and modular codebase.
Standards-based - Web components are built on web standards, meaning they will continue to be supported as long as browsers support them. This long-term stability can be a significant advantage compared to framework-specific solutions that may fall out of favor as new frameworks emerge.
Interoperability - Since web components work with any framework or no framework at all, they are highly interoperable. You can mix and match them with other components from different frameworks or libraries without compatibility issues.
Cons of Using Web Components
Learning Curve - Web components can introduce a new learning curve for developers used to working with a specific framework. Concepts like the Shadow DOM, custom elements, and template literals may take some time to master.
Tooling and Ecosystem - The tooling and ecosystem around web components are less mature than those for popular frameworks like React or Angular. This can make testing, building, and maintaining web components more challenging.
Framework-Specific Components
Framework-specific components are tied to a particular JavaScript framework, such as React, Angular, or Vue. These components are usually built using the paradigms and APIs provided by the framework.
Pros of Using Framework-Specific Components
Ease of use - Using the same framework for your component library can be more straightforward if your application is built with a specific framework. The components will integrate seamlessly, and your developers won’t need to learn new paradigms.
Rich ecosystem - Framework-specific components benefit from the rich ecosystem of available tools, libraries, and plugins. This can make development faster and more efficient, with plenty of community support and resources available.
Developer experience - Framework-specific solutions often provide a better developer experience, with features like hot-reloading, dev tools, and integrated state management that make building and maintaining components easier.
Cons of Using Framework-Specific Components
Lack of flexibility - One of the most significant downsides of using framework-specific components is framework lock-in. If your organization decides to switch frameworks or use a different framework for a new project, you’ll either need to rebuild your component library or rely on less-than-ideal solutions like wrapping components.
My Experiences
My experience with component libraries began with creating what we called an accelerator, which I developed in AngularJS before design systems became widely recognized. This accelerator was effective but had a significant limitation: it required all clients using the accelerator to also adopt AngularJS, which constrained flexibility and adoption.
My next company utilized a mix of frameworks, including Vue, Angular, Ext JS, a bit of React, and others. I experimented with off-the-shelf UI kits. However, these proved limiting and challenging in maintaining a consistent user experience across applications built with different frameworks. To solve this, I developed a StencilJSÂ Web Components component library that could be utilized across all frameworks, significantly speeding up development and enhancing customer experience.
Currently, I’m working with a React Component Library, which has proven efficient for our app, but this has also revealed limitations to improving efficiency across the company, particularly with other non-product sites that aren’t built in React, leading to the need to recreate components for each of these sites.
Which Path Should You Choose?
The decision to build a component library as web components or as framework-specific components ultimately depends on your organization’s needs, the technologies you are using, how the company wants to invest, and your long-term goals.
Choose Web Components if your organization works with multiple frameworks, values long-term stability, and needs a highly reusable and encapsulated component library that can stand the test of time. This might be slower initially but allows significant flexibility in the long term.
Choose Framework-Specific Components if your organization is committed to a single framework, values the rich ecosystem and optimized performance, and wants to take advantage of the best developer experience and tools available. This can be initially faster, but if you acquire other companies or expand to micro-sites, this may be a limiting factor.
My opinion
In some cases, a hybrid approach might be the best solution, where core (Atomic) components are built as web components for cross-framework reusability, while more specific components are built with the same framework as your app to leverage framework-specific optimizations and features.
Even if your organization currently relies on a single framework, investing in the flexibility of web components can be a strategic decision for the future. Doing so ensures that your component library remains adaptable as your needs evolve, potentially supporting multiple frameworks without requiring a complete overhaul. By carefully considering the pros and cons of each approach, you can build a component library that meets your current needs and positions your organization for long-term growth and adaptability.
Resources
Built web components with:
Examples of web components libraries