Do You Need a Component Library?

Components come from three places: You, open-source libraries and commercial libraries. Here’s how to choose between them.

Betteridge’s law of headlines says that “Any headline that ends in a question mark can be answered by the word ‘No.’” That’s true here, too: No, you don’t need a component library. But that does depend on what you mean by the word “need.”

Blazor, for example, comes with a bunch of components “out of the box” (OOB). Most of these components are pretty basic (textboxes and the like), but if that’s all you need then you don’t need an additional component library.

The DIY Option

However, a typical app requires more sophisticated functionality than the OOB components provide. In that case, one option is to do it yourself (DIY) and write your own component (which is always more fun for developers, at least initially). So, again, you don’t need an additional library: You can just build the components you need as you need them.

The issue with building a DIY component is that you’re probably grossly underestimating its cost. To get the true cost of a DIY component, you need to take a developer’s chargeback rate (which is always astonishingly high) and multiply it by the estimated time to build, test and deploy the component. If you couple that number with our tendency to grossly underestimate the costs of developing new software, the DIY solution starts to look pretty expensive.

And, of course, if you consider the cost of maintaining that component over its life and wonder who will support other developers in using that component … suddenly, the DIY solution starts to look prohibitively expensive.

Plus, you have to question the wisdom of paying to build something that already exists and whose development costs didn’t come out of your budget. The DIY option only makes sense if you can’t get the component you need from somewhere else—you should use the DIY option when you’re building something unique to your needs.

The Third-Party Option

Which leads to the third-party option: Rather than develop a component that already exists, third-party component libraries deliver a collection of components, already built and ready to be used. And that “ready to use” matters: Using prebuilt components lets you allocate more developer time to delivering functionality—your developers automatically become more productive.

With the third-party option, you can choose between open-source and commercial libraries. The obvious difference between those choices is that open-source libraries are free and, like the DIY option, eliminate any upfront cost (one way to think of DIY is that it converts the upfront cost of buying a component into the ongoing cost of developing and maintaining it).

And there are multiple open-source providers that you can choose from. For example, here’s a list from 2020 of 10 open-source providers, just in the Blazor space (one note: the link to ant-design in the article is out of date).

But … there are issues worth considering with the open-source option.

Addressing Quality (and Quantity)

While open-source options remove the upfront cost, open-source libraries can have quality issues. That’s not to suggest that open-source components aren’t well written or don’t work as advertised. Those two issues are critical and you need to investigate them if you go with an open-source option.

But, hopefully, “quality” means more to you than just “it doesn’t have any bugs.”

For example, any modern definition of quality has to include security. Commercial libraries bring years of team experience and expertise to addressing security issues in every component the team delivers. In addition, as security threats evolve, commercial vendors can move more quickly to address zero-day threats by implementing and distributing prompt (and reliable) updates.

Any definition of “quality” should also include accessibility. At the very least, for many organizations, meeting accessibility standards is a regulatory requirement. But a component library that goes beyond just meeting regulatory requirements enables you to create applications that reach more people and does it without additional effort from your developers.

A quality library will also share a common set of tools for managing the appearance of the components and, for web applications, that should be more than just “works with CSS.” You should be able to apply a theme of your choice across all your components. The library should come with multiple themes for you to use and let you tweak those themes to match your organization’s branding (and include tools to make it easy to do that as your organization’s branding evolves).

Quality also applies to how the components and their libraries evolve into the future. Because commercial libraries face competition from other vendors, commercial vendors have to stay at the leading (though not bleeding) edge of technology, just to remain competitive. Buying a commercial library means always being “state-of-the-art.”

And, while quality matters, quantity matters also. Open-source collections tend to have fewer components than commercial libraries. For example, Progress Telerik’s Blazor component library, has 25% more components than even the largest of the Blazor open-source libraries.

Productivity

In the end, though, productivity is the driving reason for choosing a third-party library. Having those “quality” features already baked into a component frees up developers to work on delivering functionality to your users instead of having to deal with those issues.

What often gets missed in the productivity discussion, though, is the impact of creating a consistent developer experience. This first shows up in the ability to customize a component to support a variety of use cases (components in a commercial library tend to be highly customizable). The productivity payoff in customizable components is that, once a developer has used a component to support one use case, the developer can leverage that knowledge to use the component to support a different use case.

In a library, a “consistent developer experience” carries that effect across all the components in the library. When common design patterns are enforced across all the components in a library, then, after a developer has used one component in a library, the developer is able to leverage that knowledge when using any other component in the library. Creating that consistent developer experience is more common in teams delivering commercial libraries than among the more fluid teams that develop open-source libraries.

But ensuring you actually get the productivity associated with a library often comes down to support: Where can your developers get help on a component when they need it? Any time that developers spend trying to figure out why they can’t get a component to do what they want is pure lost time. And, while there’s nothing wrong with searching the Net for help, commercial library vendors have professional support staff and multiple ways to contact that staff when help is needed. In the absence of support, the open-source option, like the DIY solution, just converts the upfront cost into an ongoing cost.

Picking a Component Library

So, getting back to the original question: Do you need a component library? No, you don’t. If you only need basic components or components that don’t exist in any library, then the OOB components and the odd DIY component that meets your unique requirements are your best choice.

If your needs go beyond basic components and you don’t have the cash for the upfront costs of a commercial library, then the “no upfront” open-source option will look good to you. With any open-source choice, however, you’ll need to manage the associated ongoing costs. That means making sure that the quality issues discussed here are met well enough that you can live with them.

But if you want a solution that gives you a wider choice of components, one that addresses all of those quality issues, one that delivers high levels of customization (along with a consistent developer experience), and one that also provides ongoing support while always reflecting the current state of the art, then a commercial library is probably your best choice.

And, when it does come time to invest in a commercial library, it won’t surprise you to hear: You should consider Progress Telerik and Kendo UI libraries. The DevCraft suite has .NET and JavaScript component libraries, plus reporting, testing and more. Try it free for 30 days.

Want to read more about considerations for how to choose the component library that’s right for you? I wrote a whitepaper about that!

Shortening the List: How to Choose a Component Library