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...
For further actions, you may consider blocking this person and/or reporting abuse
🤔 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! :)
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! :)
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.
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)
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 :)
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.
Thank you very much Mr Andrzejewski for a fantastic series. :-)
Thank you for the kind words! If there is any topic that you are missing, please let me know so that I can write about it :)
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.