Things to Consider When Choosing a Component Library
Tags: javascript, webdev, mobile, components
Published: 2020-10-11 11:06:52

Modern UIs are composed of multiple components. Popular component libraries include components like:

* Buttons

* Forms: input fields, select elements, checkboxes, radio buttons

* Dialogs, modals, and popovers

* Cards

* Tabs

Some of the most important things to consider when picking a component library:

* Maintainability: Who are the people behind the library? Is it a company, a group of passionate open-source contributors, or a one-man army?

* Flexibility: To what degree can this library be customized to your needs?

* Ease of use: How difficult is it to use and integrate this library into a project?

* Popularity: Is this library used by millions of developers or just a few developers in one company?

* Dependencies: How much does this library depend on other third-party libraries?

* Documentation and resources: Where and how can I get tutorials and other information about this library?

In this post, I want to take a closer look at this with a real-life example. The project will be an [Angular](https://angular.io/) web application and I’ll use the following component libraries:

* [Angular Material](https://material.angular.io/): A framework that contains material design components for Angular.

* [Bootstrap 4](https://getbootstrap.com/): The most popular CSS framework, originally created by Twitter.

* [ngx-bootstrap](https://valor-software.com/ngx-bootstrap/#/): An implementation of the popular Bootstrap framework which is intended for Angular applications.

* [Nebular](https://akveo.github.io/nebular/): A customizable Angular UI Library with multiple components, themes, and further feature modules like Auth and Security.

While we’re taking a closer look at component libraries many of these aspects apply to libraries and frameworks in general.

## Software Maintainability

Software maintainability is defined as the degree to which an application is understood, repaired, or enhanced. If you think about it: most SaaS are never finished. New features are implemented while countless bugs are squashed and new bugs are inadvertently introduced. So maintainability is an important factor for the long-term.

Let’s look at how our candidates fare:

* **Angular material** is mainly driven by developers working in the Angular team which means they keep up with the Angular ecosystem.

* **Bootstrap** has a lot of contributors and a rich ecosystem, so it will be supported for quite some time.

* **ngx-bootstrap** is developed by the software development company Valor Software. While Bootstrap itself is quite mature, ngx-bootstrap is more or less bound to Bootstrap.

* **Nebular** is mainly driven by the software company Akveo, which has experience in open source projects. They offer professional services if you need consulting or further help to develop your application.

## Flexibility and Configuration

Different products have different needs, so UX and design can vary a lot. Take news websites — while [TechCrunch](https://techcrunch.com/) and [Verge](https://www.theverge.com/) both report technology news they differ in their visual representation and features.

Let’s look at how our candidates fare:

* **Angular Material** provides multiple themes and can be customized using SASS. The [Angular Component Dev Kit](https://material.angular.io/cdk/categories) (CDK) is a set of behavior primitives for building UI components in a style-agnostic way.

* **Bootstrap** can be customized using SASS. There is a variety of free and paid themes available.

* **ngx-bootstrap** can be customized the same way as Bootstrap.

* **Nebular** provides decent extensibility. You can use SASS or CSS Custom Properties (aka [CSS Variables](https://medium.com/better-programming/how-to-make-your-website-themeable-with-css-variables-81468d7c6f72)).

## Ease of Use

Often in life, we pick things that are easy to use and require the least amount of effort. The same applies to picking the right library for a job. Some libraries can be installed with one command and you can use them right away.

On the other hand, some libraries depend on other libraries or need more effort to set up. Typically, integrating a library becomes harder if it requires other libraries or tools. Angular CLI has a great feature called [schematics](https://angular.io/guide/schematics) — template-based code generators for transforming a software project by generating or modifying code.

* **Angular Material** can be installed with one command by using the Angular [schematic](https://material.angular.io/guide/getting-started).

* **Bootstrap** requires jQuery and Popper.js, so all three of these libraries need to be installed. Since it’s primarily a CSS framework you can import parts of the library to keep your bundle sizes as small as possible. For example, it’s possible to just import its UI components but neglect the grid if you want to use another grid solution.

* **ngx-bootstrap** needs Bootstrap so both libraries need to be installed. You also need to include the Bootstrap style. There’s a handy Angular [schematic](https://valor-software.com/ngx-bootstrap/#/documentation#getting-started) to automate these steps.

* **Nebular** requires the Angular CDK so both libraries need to be installed. You also need to include the Nebular theme. There’s a handy Angular [schematic](https://akveo.github.io/nebular/docs/guides/install-nebular#install-nebular) to automate these steps.

## Popularity

The popularity of software as a metric is interesting. On the one hand, popularity can be an indicator of a certain degree of quality — if thousands of developers are using the library, posting good things about it, it seems a good sign for the future of the project. On the other hand, popularity can be faked. Or it’s not applicable —[when a joke project has more stars than most GitHub projects](https://github.com/auchenberg/volkswagen) we can’t take popularity as a serious metric without taking a closer look.

Let’s take a look at how our candidates fare when it comes to popularity:

* **Angular Material** has ~20k GitHub stars and more than 430 contributors. There are new (beta) releases rather frequently. There are quite a number of open issues but many are being resolved by the team behind Angular Material.

* **Bootstrap** has ~141k GitHub stars and more than 1100 contributors. New releases are not as often as for some more recent projects. However, Bootstrap is quite mature at this point and therefore focuses more on stability and consistency than piling up features. For a project of its popularity, there are quite a few open issues.

* **ngx-bootstrap** has a few thousand GitHub stars and around 100 contributors. New releases are not seen as often as for some more recent projects. As ngx-bootstrap is a wrapper around Bootstrap the project won’t make drastic changes, which helps with stability but hinders innovation.

* **Nebular** has ~6k GitHub stars and more than 80 contributors. There are new releases rather frequently. The project is still rather young but gaining traction.

### Dependencies

Most software projects have third-party dependencies. Especially in the beginning of a software project, when you want to build an MVP quickly, you don’t have the time and resources to implement everything yourself. This is one of the most compelling reasons for choosing a component library. Successful companies like Airbnb or Atlassian often create component libraries, which are sometimes even open-sourced. However, it can get increasingly difficult to do.

Let’s look at how our candidates fare:

* **Angular Material** requires no further third-party dependencies.

* **Bootstrap** requires jQuery and Popper.js. Luckily, jQuery probably won’t be required anymore when Bootstrap 5 will be released.

* **ngx-bootstrap** requires Bootstrap and Angular. However, you don’t need to include further scripts like jQuery or Popper.js, which are normally required when using Bootstrap.

* **Nebular** requires no further third-party dependencies except Angular.

## Documentation and Resources

When you approach a new topic, tool or language many developers search for information on the internet. There are a few ways to get information: posts on Stack Overflow, official documentation, and how-to tutorials. Raise your hand if you’ve ever copied and pasted an error message into Google and clicked on the first search result!

* **Angular Material** has good documentation with examples. I especially like that you can edit the examples in the documentation directly in your browser using [StackBlitz](https://stackblitz.com/).

* **Bootstrap** has good documentation with examples for all components. Since it’s a widely used framework there are lots of tutorials and external resources available for Bootstrap.

* **ngx-bootstrap** has good documentation with examples for all components.

* **Nebular** has good documentation with examples for all components. However, it does not have as many external resources as some of its older competitors.

### Evaluation

Now that we’ve talked about some important decision factors for choosing a component library we can evaluate our choices:

* **Angular Material** is a good choice if you like material design.

* **Bootstrap** is a solid choice if you want a simple and easy to use solution. However, with growing project complexity Bootstrap might feel too barebones.

* **ngx-bootstrap** is a good choice if you want to use Bootstrap in an Angular project. However, you implicitly rely on Bootstrap.

* **Nebular** is a great choice and my personal winner. It’s heavily customizable and there are useful extensions around it.

As you can see there are always tradeoffs to be made. It depends on your needs — often, a perfect solution is not available. In a smaller project, all you need may need is basic components like buttons, while in a larger project you often need things like forms, grid systems, tables, and more.

## Creating a Component Library? Evaluate Carefully

As mentioned above, successful companies often create their own component libraries. If you modify 90% of the code to make it work for you, you might be better off creating your own components.

This was the case for Airbnb with the popular [react-dates](https://github.com/airbnb/react-dates) project. They tried out solutions and had to change so much code that, at some point, they decided to build their own. The answer to the question of whether to create a component library is, as always, that it depends.

When I talk creating your own component library I’m not talking about making a fancy button and calling it a day. There are important aspects you need to consider:

* Development costs: Someone needs to actually implement the components.

* Maintenance costs: R.equirements change and so does software. Be careful — the effort of maintaining code is often underestimated.

* Accessibility: Popular component libraries often make sure to incorporate accessibility. Sadly, in many projects accessibility is quite neglected. [The Angular CDK includes multiple tools to improve accessibility](https://material.angular.io/cdk/a11y/overview), like implementing keyboard navigation.

* User experience: Popular component libraries like Bootstrap are used on millions of websites in various ways. This means users have experience with them and are accustomed to them.

## Conclusion

Thanks for reading this post. As you can see, picking the right component library can be difficult. Choose wisely as it will be more expensive to change it later.

If you’re a startup, a single developer, or if the project is not too complex then I recommend picking an existing component library. However, at some point, you might reevaluate whether it makes sense to create your component library when you find that existing component libraries don’t fit your needs anymore.

What makes you choose one component library over another? Let me know in the comments.