In my career as a developer, I have been using component libraries since the very beginning. These packages full of useful elements were helping me build applications for both open-source and enterprise applications.
But using them comes with advantages and disadvantages (like with anything in web development) so I decided to summarize my experiences with them in this article to share the knowledge that might be useful for you 😉
If you have other experiences with component libraries, please do not hesitate to add comments and share your thoughts. This is rather a big topic that I think everyone can contribute with their opinions.
What is a Component Library?
Component Library is a collection of reusable and generic components that you can add to your project for several different reasons like:
- Acceleration of Development
- Standarized patterns across the project
- Useful integrations
And probably many more.
These components are usually packed inside an NPM package that you can easily install and use across your application. Thanks to the reusability and customizability these elements can be used in many different scenarios.
For easier development, testing, and automatic documentation, tools such as Storybook were invented that are a must have for any modern component library.
Storybook allows to also integrate with popular Design tools such as Figma so that you can have a direct sync between the design and development teams.
Examples of Component Libraries
There are many component libraries available on the market that you can easily setup and start using in minutes. To be honest, I would say that there are actually too many generic and agnostic component libraries available and because of that, it is rather difficult to choose one of them. The generic library is the one that includes components such as buttons, labels, fields, forms, etc. Basically the elements that you may need in any type of project.
For that, you could use library like Vuetify for example:
It delivers several out of the box components that you can use to build your next app. And there are many many more examples of such libraries.
However, there are also examples of libraries that are focused on certain area of business like e-commerce, healthcare, travel, etc. And if you ask for my honest opinion, I would say that these are actually a game changers. Why? Because they contain components for the elements on the page that can be really difficult or time consuming to implement from scratch or even by using component library such as Vuetify.
Let's take a look at the example of Storefront UI:
It comes with useful components such as ProductCard, ProductReview, ProductSlider or OrderSummary that can help you easily that normally would take days to implement. And by using SFUI, you can utilize the power of these components by simply importing them in your project.
My experience with Component Libraries
I might be extremely unlucky but in my current company this is actually the 3rd time for me to join a project where a component library was used from the beginning and after some development time, I needed to spend several days to remove this component library.
In my particular case, it was about Vuetify component library. Don't get me wrong, Vuetify is a great collection of elements that are based on Material Design and I can totally see multiple use cases for it like MVP projects or small applications.
However, for huge enterprise applications that I was building while working for the past three companies, using a component library such as Vuetify is actually more troublesome than it is worth. Why? Because these libraries are aimed to be as generic as it is possible and because of that if you need certain component to behave differently than it was initially planned, the amount of workarounds that you would need to do to make it work is basically not worth it.
And believe me, removing a component library (that is basically used anywhere in the application) while still developing new features for the existing and production application is a really difficult task.
To give you a better example, let's imagine that you are running a tattoo shop and one of your customers who has his whole body covered tattoos decides that he does not want them anymore. So he asks you to remove them, you start the procedure, and then he decides to start moving all the time, talking through the phone, eating, and stuff like that.
So yeah, I had quite a struggle with these component libraries. But this doesn't mean that I think they are not usable. Take a look at the next section where I am trying to answer when you should use them.
Should you use them?
Interestingly, this is not a correct question. The better one would be to ask: When should you use Component Libraries?. Why? Because as with any tool/service/package they were invented to solve certain problems and for other situations they might not be a perfect fit.
I would say that you should use Component Libraries at the very early stage of the development of your next project. Let's imagine that you are building a Proof of Concept that is aiming to validate some idea. Then, using library such as Vuetify would allow you to very quickly have something that works and looks decent. You validate your idea, then you decide to start from scratch with other technology stack. And I can completely recommend that. Just make sure to not do what was done in one of my projects where Vuetify was selected for the PoC stage, and later on there was no time to refactor it and we ended up developing with it for more than a year. If you would ask what we replaced it with, we have decided to go with pure Vue 3 and TailwindCSS. It gave us the most flexibility and customizability we wanted while building our product.
Let me know in the comments what are your thoughts on that 🙂
Top comments (15)
🤔 I'd challenge or point out that there's a risk of either missing out (or spending considerable effort) on nuances such as keyboard navigation, accessibility, performance(, ...).
Custom components must also be bug-fixed, tested, maintained, and documented.
The devil is in the detail. Re-inventing the wheel also comes with a cost.
But still, many good points were made in your post!!
As you wrapped up your article - 'it depends'.
IMO headlessui is a solid role model that provides fundamental components that cover the most common/basic needs - yet it does not aspire to be a comprehensive component library.
Thanks anyway for starting the discussion!
Thanks for providing your feedback! Really valuable! :)
Thanks for sharing your insights, your article is very well written! I use a private company components library at work and public libraries for personal projects. Since we're a pretty small team at work, our component library isn't maintained very often and the "nuances" and subtiles details are pretty much absents.. So for me it's public libraries all the way! There's some great choices that give you only the barebones and allow you to get much freedom like with MUI Core
I'd say it depends.
If they're simple components, you might be better off without the hassle of learning its custom syntax.
But some components can be really difficult to implement from scratch, e.g. a spreadsheet-like data grid with virtualised scrolling.
I agree wholeheartedly. It's a tradeoff with resources as well. Public Component Libraries get you up to speed fast, and at a certain level of maturity they will inevitably hold you back.
I do see value from that point on using non public, organisation based component libraries though, since they sit very close the the organisation and branding and specific domain context. This is why organisations with a certain scale and size start building their own, to suit their needs rather than rely in generics. And then still, it will make sense to expose those parts as granular as possible (on token level) to avoid lock in on a certain stack (such as Vue / React / Svelte / Angular).
(I am partial because I'm in the team that maintains our private component library)
Really good comment. Thanks Joran! :)
Nice post! I have the same experience as yours with component libraries. In fact, we are also getting rid of CSS frameworks. Bootstrap in our case.
I see. This is even step further as you are getting rid of even CSS framework. Could you share what was the decision behind it?
Well, the decision was based on more power of customization and the possibility to add functionalities that general components from 3d party libs don't have.
So we sacrifice time from the team to create our own component library and in the future, we will probably remove Bootstrap in favor of Flexbox and CSS Grid.
I think the main reason could be performance, and that has other advantages like, loading speed, improved SEO, etc.
I decided to remove the public component library I was using.
Why? Because I couldn't wrap my head around how to use some specific parts with the front framework I had. Also it got bugs, and I couldn't get rid of myself (unless I forked their github and tried to fix the bugs myself).
I decided that, although it's nice to have ready-made components, the lack of customization, the difficulty to mitigate some lacks, and the bugs, was not worth it, and that I would certainly spend a bit more time creating them myself (I only use simple components for now), but at least they would be tailor-made and perfectly integrated.
I had the same issue with a PHP lib I was using. I had to fork it (because I didn't want to write it from scratch) and fix the bugs myself, which worked out in the end.
Thanks for sharing your point of view. I has similar case as well :)
Feedback from a 20k+ employee company perspective: you will absolutely fail writing and maintaining your own component library. Getting components to work well for all users is hard. To me this sounds like visual design concerns won over user experience concerns... Which is fun in the short term, but ends up hurting you more and more the longer a project survives. I would recommend the literal opposite approach this author recommends: for small POCs and projects it doesn't matter at all, but for serious projects it's irresponsible to not use an actually maintained component framework. Writing reusable, accessible and sensible UI components is hard. Not too long ago I looked at 4 'ad hoc' implementations of a dropdown (all implementing the same visual target), 1 didn't work with the keyboard at all, all 4 didn't work with screen readers and 3 of them had issues on mobile devices. And let's be real, dropdowns aren't even remotely the most complex UI component.
The true art form though is to learn to manage requests from stakeholders. To be able to say "no", because the technical debt of applying hacks to well maintained component libraries is a bad idea. Having the right people be a part of the design process can make a huge difference.
(All this assumes that you need more than some buttons and text fields 😅. This comment assumes 'serious web applications', not 'websites'. I recently saw a project load in vuetify I think for shadows, cards and buttons... Which isn't necessarily a problem, but I think learning basic CSS might've made more sense in that case)
The quality of component libraries varies across the board and in some bad ones it may be more difficult to customize components to your needs. Overall I disagree with your argument though that you shouldn't use them for more complex/custom projects. Having pre-built low level UI components like buttons and form fields saves a boatload of work when building enterprise applications. Its like having 1000 more people working on your team.
You shouldn't just pick any library though. Do some research, pick one that has a lot of maintainers, good docs about how to customize it and specifically states they're geared towards accessibility. A good component library should always have accessibility compliance as one of their main focus points.
To be more safe when using a component library, you can use the adapter pattern. That is: wrap the components from the library in your own adapter components and use those in your project. This makes swapping out component libraries easier if you ever need to.
Hey thanks for your opinion!
In my company projects cases, the decision to go with Vuetify was based actually on a research you mentioned and in the first stages of the development it was actually working well.
The real problem arised after X months of development when we needed to adjust the components to the new design, new functionality, etc. Because of that (and the fact that we were using Vuetify still) we had to make several workarounds to make the components work the way we want it (not the way the library author wanted it). And it was solid days playing with CSS, JavaScript, etc.
The adapter pattern is a good idea (and we have been utilising it there) but it still wasnt enough for our cases.
Dont get me wrong, I completely understand your opinion and I can see cases where a proper research and proper adapters could make it work. But in our case it was just a lot of time that we needed to spend to make it work, to eventually migrate to pure Vue + Tailwind. And in this article, I was sharing my experience. So thanks one again for sharing yours as it allows developers reading this article to see a different opinion and based on that, create their own opinion :)
Thanks for sharing and really help to assured my doubt about using Component Libraries in projects.