Log in to like this post! UI Component Libraries - Build vs Buy Jason Beres [Infragistics] / Tuesday, September 6, 2022 “I never want to build another calendar component again for the rest of my life. I also like react-select.” I came across this on reddit while browsing through discussions. But then I also read: “When you write your own (library) you will learn many more things like accessibility, roving index, focus management, auto ID, etc. All these make you appreciate the complexity of a good and stable UI package.” And here I am trying to answer the question “Building vs buying a component library: what to choose?” and help developers make a decision that won’t cost them: Their time in vain, when in fact they are pressed by time itself to build fast quality IT solutions. Their money in vain, when in fact they work with strict budget and the company cannot allocate more for a project that’s estimated to cost X amount of money and X amount of per-hour wage. Their trust in their own programming skills, when in fact they can neither use a third-party UI library for the specific purpose of an extremely niche app. Nor can they build, for instance, an Angular Pivot Grid from scratch, while another developer handles a different select component at the same time, that must support multiple features. So, the two things clash in inconsistent UI and UX in the end. Either way, these are all stressful scenarios that can quickly get a single project from being mission-critical to mission impossible. What to do, then? What’s the best way to build your web application? Should you go with pre-built UI components or is it better to build your own? And why use a component library in the first place? Here are all the contexts, factors, advantages, and disadvantages you must consider before you trade off one option for another. UI library at a glance Context and key questions to ask Buy vs Build filtered through 7 factors Component reusability External dependencies Software updates UI library documentation and learning resources Special Features Technical support Cost, Licensing and ROI My personal take and Ignite UI What Is a Component Library? In the simplest terms, a UI component library is a comprehensive toolkit that combines prebuilt feature-rich components/controls, API, guidelines, sample apps, integration scenarios, code examples and extra tooling that streamlines app development, helping developers build great interface faster. The components can be also customized, reused, and extended to gain from branding options and more flexibility. But when it comes to addressing key aspects like the needs, purposes, skills, type of app, and more, the options for handling development are boiled down to: Building in-house UI library Buying a third-party component library Choosing an open-source software (OSS) To decide which one is the best approach for you, let’s first look at the bigger picture and see the broader context in which each of these three options can be potentially applied before we adjust our narrative lens and zoom in. Company size and teams Know-how and experience The app, its purpose, and client 1. Company size and teams One of the first things to consider when trying to figure out whether to buy or build a toolbox with components is the size of your company and how many programmers are involved in the app building. Questions to ask in this context: Does the company operate in a highly regulated field? Is it small, medium, or large size enterprise? Does it work with fusion teams? Are there remote or any citizen developers in the picture? If it is a large organization, do the teams already use any type of a UI library? What do the company and the team want to achieve when implementing one such toolbox – Standardization? Continuous reusability in the long term? Accessibility compliance? Full control over how they craft software? Spend more time for the app business logic and not having to create everything from scratch? 2. Technical know-how and experience When it comes to deciding whether or not to use pre-built UI libraries or create one of your own, weigh in the background of the IT team. If developers don’t have sufficient knowledge in constructing comprehensive components that will serve long-term/short-term goals (depending on the specific needs, of course), then it’s not worth investing time and efforts at all. This will also require additional resources from more experienced devs to document code and processes. Questions to ask in this context: What practical and technical know-how do developers and designers in the team have? Have they used any UI libraries before and to what extent? Do the designers and the people behind UX at the company have enough experience to design components professionally? Are they quick-learners and ready to adapt to new best practices and automation? Or have they tried their hands on building components from scratch and how reusable were they? What frameworks and technologies do they work with? How ready are you or your team to handle dependencies and keep up with browser versions or framework updates? Will you have the time to keep you in-house library up to date? How much front-end work that must be done? 3. The App, Its Purpose & The Client Finally, your decision must be driven by the project you are going to work on, what and how it will be used and by whom. Questions to ask in this context: Do you need reusable components for a long-term project that will require elimination of repetitive tasks and the use of the same modules and code? Or is it a one-time, very specific, specialized use case that you will never use again and therefore won’t be applied in multiple scenarios / apps / projects? Are you building for an external client in a tight niche that doesn’t accept one-size-fits-them-all solution and instead demands heavy customization, entails specific design specifications, and therefore imposes tasks that will require from you to handle and troubleshoot issues that are less common? Will out-of-the-box features and functionalities do the job for you and are you/the team ok with capabilities that are available for all users by default? Are you an in-house system for your organization and do you need to speed app development and improve collaboration between cross-functional teams? Is your aim to build unique products and innovate so you need full control and unlimited scenarios/functionalities that can be changed and updated whenever you decide? Buy vs Build: Pros and Cons of a Third-party Component library, in-house UI library, and OSS For the purpose of this section, I will filter each option through 7 factors and will highlight the trade-offs of each option. Factor 1: Component reusability This surely achieves standardization across projects, especially if they are continuous ones and you plan on using the same code different times to save you some manual efforts and repetitive tasks. However, there are certain components, especially for relatively new frameworks like Blazor, that are particularly difficult to build from scratch. I don’t mean a button here. Think of Data Grids that can be fast and comprehensive enough to deliver accessibility compliance, all types of columns, cell, and row actions, data manipulation, custom visualization, and so forth. COMPONENT REUSABILITY ADVANTAGES DISADVANTAGES Commercial UI libraries Built to serve and comply with as many devs, teams, and projects as possible, they can be applied to different apps. Can quickly troubleshoot common challenges. Consistent styling to multiple components. Achieve standardization faster, and result in an instant UI/UX consistence. May require some training and guidance before achieving the desired level of knowledge sharing and accelerated app development. Prioritization of niche features and functionalities can take more time. In-house libraries Gain know-how that can be used for other purposes and projects that require modular development. Only design and develop the components you need with the level of reusability you want. Faster prioritization of important features / functionalities. Component is purpose built for the current use-case, no consideration into reuse across other teams / projects. Long-term maintenance and cost is not considered up-front. No consideration for accessibility, a11y, Section 508 compliance and other must-haves for components. No Documentation, so APIs are only known to the developer that created the component, making it difficult to use by others. OSS Many OSS projects reproduce effort and use the same code. It’s easy to propose new feature/functionality that the community may benefit from. The majority of OSS projects are abandoned within 12 months, and even more gain zero community support. Cannot yet provide full advantage of component reusability. You will spend sufficient amount of time debugging, figuring out what functionalities are missing, and adding them later. Factor 2: External dependencies The more dependencies you have to add in the future, the more complex what you initially wanted to simplify becomes. It’s important, then, to consider all options in this regard. EXTERNAL DEPENDENCIES ADVANTAGES DISADVANTAGES Commercial UI libraries They are kept to minimum and if you have to add any it’s mostly just one. The level of complexity is close to zero. You won’t deal with conflicts between libraries. But just in case there are any, the team behind the paid library handles it and usually they catch this type of problems early on. It’s only limited to the third-party library itself. Resolving this dependency package may take extra time because you rely on external support. In-house libraries They multiply project’s complexities because you have to handle outdated dependency on your own. You are responsible for security risks in 3rd party OSS dependencies. OSS They multiply project’s complexities because you have to handle outdated dependency on your own. You don’t know if it is a second-party or third-party dependency. Factor 3: Updates How many updates can you or your dev team handle daily, per month, per year…? Each of the three options certainly has different pros and cos and it’s crucial to evaluate them in regards to updates before you make up your mind. SOFTWARE UPDATES ADVANTAGES DISADVANTAGES Commercial UI libraries All gets upgraded to the latest framework or browser version. Updates are done by the external team behind the commercial library. You don’t have to reallocate people or deal with it on your own. With smooth testing processes in place which helps teams do handle upgrades and ensure stability. Continuous projects usually have a roadmap with the future in mind and get regular releases in accordance. May happen to have too many upgrades. Alpha, Beta, RC versions might be released daily in order to address high-priority items. In-house libraries You get first-hand information about the latest releases because it’s you who have to keep track of updates. You handle it all. Home-grown libraries are usually never updated and are out of date even by the time they are put into product. OSS You may land on a well-maintained open-source project that gets updated every time. Continuous projects usually have a roadmap with the future in mind and get regular releases. May happen to have too many upgrades. Only the largest, well-funded OSS projects are kept up to date on a regular schedule. Factor 4: UI library documentation and learning resources A well-written, comprehensive documentation, containing demos, examples of implemented components as well as additional resource sections and knowledge base is key. Not documenting your coding or without having a ready-made one, expect hard times building even a single dropdown list or a paginator. Let alone more complex components like Blazor DockManager, or composite visualizations like Angular Financial/Stock chart. DOCUMENTATION AND LEARNING RESOURCES ADVANTAGES DISADVANTAGES Commercial UI libraries Always come with detailed, easy-to-read, up-to-date documentation and not “do it once and forget”. May include live-editing samples that help developers gain better understanding and feeling of the code/UI components that they will be dealing with. Deliver additional learning resources, blogs, FAQs, how-to videos, tutorials, sample apps. Usually have large communities on Stack Overflow, Discord, Medium, Reddit, GitHub. Require commitment to documentation and learning. May take some time getting used to it. In-house libraries Require additional working hours and dev time allocated to write and update it. Most organizations don’t have resources to write documentation on the applications they are brining to market, let alone the home-grown UI components used in the application. OSS It is difficult to find OSS projects with documentation unless they are very large and well funded. May take too much time getting used to and learning all the things that are added and keep being added regularly or irregularly. Factor 5: Customization Getting and delivering all in an app takes updates and changes. So how flexible do you need your UI library to be and how flexible can you make it? Don’t overlook this factor when you opt for one solution or another but keep in mind that sometimes components/functionalities that are highly configurable and allow everyone to make changes to them may result in a hard to maintain code and could break a lot of other "things" that no one is familiar with or are very specific. This is why we have custom Angular components that are simpler than the Combobox component, for example. Customization ADVANTAGES DISADVANTAGES Commercial UI libraries Comprehensive libraries like Ignite UI make sure to leave room for customization, accessibility, internalization. Professional components are super configurable. Include interactive parameters that users can easily change. Work equally good with design systems and low-code/no-code app builders. Some features come out-of-the-box. Built to fit common/all scenarios (which can be an advantage as well). In-house libraries You have unlimited options and ways to build special features and change components whenever and however you want. You can decide on the exact components and functionalities. Home-grown libraries are purpose-built for a specific need, long-term customization / extensibility is not considered up-front. Requires more time building, testing, validating, coding, documenting. OSS Usually, super configurable. Purpose built with features and extensibility added once community traction is gained or funding is achieved. Factor 6: Technical support Apart from benefiting from detailed and explanatory help docs and other learning resources, getting qualified technical support is also something that matters. TECHNICAL SUPPORT ADVANTAGES DISADVANTAGES Commercial UI libraries There is a dedicated technical support team to handle all requests and questions and provide solutions. Timely and qualified help. In-house libraries You deal with all issues on your own or request help from someone with more technical know-how. You or your team will have to respond to all demands and requests at some point, compromising on vital tasks and quality coding. OSS In case the OSS library of your choice has a large community effort behind it, then you have high chances of finding a solution. Can collaborate. Boosts your problem-solving skills backed by a community of fellow-devs. If not, you have to request additional help or try deal with it or your own. No dedicated technical support Or the technical support is based on the OSS library popularity and community". If the library is new and unknown, there is no community behind it, to back it up. Factor 7: Cost, Licensing and ROI Lastly, it all comes down to how much everything will cost and does the price pays off in the future. COST, LICENSING AND ROI ADVANTAGES DISADVANTAGES Commercial UI libraries Libraries like Ignite UI offer different packages and license options to fit budget and needs. With available trial versions to explore and see how products work before committing on 100%. All packages are immediately upgraded after important releases of frameworks like Angular, Blazor, React, Web Components, and more. Offer per-developer subscriptions. May not include trial of entire product and all components or features. Depending on the product, could be expensive and full-featured plans could not be as affordable. Sometimes there is no monthly subscription and only yearly. In-house libraries May be the fastest solution especially when you currently don’t have resources for an expensive third-party UI component library. Usually, the cost multiplies by dev time required for building the library, then maintaining and upgrading it, writing documentation, handling issues, additional tasks, and so on. Research shows the cost is 10x to 50x more than ROI on a home-grown solution. OSS Works well if you find a solution that matches exactly what you need, otherwise you are spending time customizing a code-base that you don’t own the IP for. Thorough understanding of OSS licensing is required, putting your IP at risk. Cost multiplies by dev time required for building the library, then maintaining and upgrading it, writing documentation, handling issues, additional tasks, and so on. Almost impossible to estimate the cost and the ROI. My Personal Take and Ignite UI On a final note, what is Ignite UI and why is it a good solution for your business? The days when IT teams relied on clunky software development processes and had to build everything from scratch are long over. It doesn’t matter if we refer to app building for external clients or in-house solutions, or whether we discuss things like UI libraries and toolsets. It’s always the same. If tools can accelerate and ease app development and achieve better UX while complying with the most modern principles related to theming, responsiveness, a11y, and rapid app development, you almost have no choice but to use them. You will be hard-pressed to find a development manager or executive that will approve a software development project that could cost into the millions of dollars, take months or years to complete, that isn’t part of the core business or domain expertise of your company. And worse yet, is completely out of date by the time it is put into production, as decisions were made months or years prior, while modern UI frameworks are shipping multiple times per year with new features, security updates, and bug fixes. When it comes to component libraries, the comprehensive ones really do cover the majority of design and application requirements with built-in extensibility that one might think of. Just like our Ignite UI that offers a toolbox for Angular, Blazor, React, Web Components, and other popular frameworks. Each library receives continuous enhancements and features suitable for any business, and most of all it provides consistency across frameworks. I can pick and you can pick from dozens and dozens of available components, like Grids, Charts, Data inputs, and even file exports. You get a chance to become part of a strong community that will not only help you achieve anything with the framework of your choice but also grow as a developer/designer, while bringing significant cost savings to your company. For additional details on the ROI of reusable component libraries and the cost of build vs. buy, read our whitepaper.