Imagine that you work for a software company that is a about 10 years old. Over the years, many engineers have come and gone, and they brought their favorite UI component libraries to help with the implementation of features. As more engineers come, so did the number of preferred UI libraries. In some cases, designers came up with something that did not exist in any of libraries already in use. Because the goal was to implement features as fast as possible, there was no time to create your own. So what do you do? Most likely you searched for open source library that had the component you needed and introduced it into the source code.
This was the situation our engineering organization found itself in after a decade of development with very little focus on scaling the frontend. The list of libraries being used was lengthy, including several modern frontend frameworks and versions. The list included AngularJS, Angular, Telerik, several versions of jQuery, jQuery UI, Bootstrap, Angular Material for both version of Angular, and KnockoutJS. None of the UI components were compatible with the other technologies and the UI elements looked and functioned differently from page-to-page.

We needed a solution that would be capable of working with all these technologies to maximize the reuse of our code. There was no UI library that met our need of being universal. One option was to continue with Angular Material, but that would mean that the legacy areas of our application could not take advantage of feature rich UI components.
We narrowed it down to Web Components as our solution, but that meant we had to build our own library . There were some reservations because developing your own component library is costly and if management does not invest in it, they tend to be abandoned and never mature. In our case, we also needed a set of consistent UI components to create a consistent user experience. The solution need to work anywhere in our stack. Our design team had already adopted Material Design as their design philosophy and the effort modernize our applications was already on its way using Angular and Angular Material. It would be years for a full rewrite.
The next problem we had to solve was how to create Web Components that are future proof, work with or without a framework, as well as work in IE11. I was already familiar with the Ionic framework and had followed the development of their StencilJS compiler they use to develop their components. For us, Stencil met our needs, and it was easy to learn. It included many of the familiar syntax and features in Angular and React and it was cross-browser compatible.
Once we received the buying from other members of the team, I spent the next 8 months developing a set of components that would replace future use of all other UI components from third-party libraries. When developing I started with the most common elements, form controls such as input fields, selects, radio button, buttons, etc… The design matched the Material UI components There was no design needed to get started. Within 6 months, I was able to release the first version to the engineering team for production use. It included the most common components we used.
To speed up development, our components did not match feature by feature with the Angular Material component API. Rather, we added the basic functionality, and as new functionality was required, it was introduced in a backward compatible approach. The API for each component matched the API for the Material ones to make it easier to replace them in the future. This approach allowed us to quickly get something reusable to production without bloating the components with extra features that were not required at the time. We also chose not to go back and replace the other library components. Rather, as we touched a feature we would replace them with our own.
This solution worked for our team. It may not work for everyone. There are many things to consider when writing your own component library. In particular, whether the team has the frontend expertise to execute, and if the company will invest the necessary time resources to mature the library to extract the value.
One of the advantages with using web components is that you are future proofing your UI from future technology trends. There are many Frontend frameworks am there will be many more to come as the web evolves. StencilJS specifically solve several “getting started” issues for our team. First, development was familiar to Angular and React and it is well documented. It also allows for lazy loading and caching components which speeds up the user experience with faster page loads.
How is your team solving their frontend problems?