I currently work as the Lead Frontend Developer at my work. When I joined the company they didn’t have any Frontend Developers so I was the first and with that came a bunch of important decisions.
I realised that building a component library is not a quick endeavour.
- What stack are we going to use on the Frontend?
- Which development tools?
- Which package manager?
- What’s our workflow going to be?
Luckily for me, the community in the Frontend world is great and there is enough information out there and enough great tools that it’s not overly complex to pick a bunch of tools that will serve you well.
However, when it came to deciding about styling it was a little more tricky. I played with the idea of building our own component library and styling everything from scratch but then when trying this approach out on a simple button I realised that building a component library is not a quick endeavour. There is so much to think about and so many edge cases to cover that it was better for me to choose an existing component library.
There are also plenty of warnings out there about going with an existing component library but in my opinion it really depends on your situation.
There are also plenty of warnings out there about going with an existing component library but in my opinion, it really depends on your situation. If you have a designer and a few Frontend developers and a clear vision of what your whole style will be like then sure, a custom component library could be the best way forward. However, I was a loan Frontend developer who had to build rapid prototypes in order to show potential investors in order to raise capital for our small company. I needed to go with an existing solution.
What Component Libraries were available
When I had made this decision it was time to whittle down a shortlist. I have used quite a few component libraries over the years so this was the list I came up with:
There are some more but these were the main ones I was seriously looking at.
My Decision-Making Process
Let’s start with Bootstrap.
Bootstrap
For some reason, I have noticed that amongst seasoned developers Bootstrap is quickly dismissed, even mocked sometimes. “You used Bootstrap?! Why?!” I would hear it in some mocking tone like this library is somehow beneath them.
On the flip side, it seems to be the go-to library for junior developers or backend developers who just want to put together some quick-and-dirty UI. Which I also find interesting. It’s not like it’s really any easier to use than the other libraries and it’s not as if it looks better but still seems the default choice in many situations.
Bootstrap (at the time of writing this) is on version 5. If you check out the documentation you find there are a fair number of components and plenty of options in terms of customisation.
I have noticed that amongst seasoned developers Bootstrap is quickly dismissed, even mocked sometimes.
For my situation, I didn’t choose it mainly due to the fact it was utility class based and I didn’t think the default styling really suited the use case of the applications I had to build. It’s pretty easy to recognise an MVP built with Bootstrap and it reminds me of the apps that used to get built when Bootstrap first came out. They were always clunky and just looked… like Bootstrap apps. I just don’t like the design. Maybe I am a developer snob after all.
HeadlessUI
With HeadlessUI I quickly dismissed it for two reasons:
- I had never used it before and it looked like I might spend too much time styling and tweaking individual components rather than building out features that were quickly needed.
- You have to use it with TailwindCSS. Whilst I like Tailwind for static sites I think using Tailwind on the dynamic sites I was building out again would require too much time styling and building out a component library.
It basically came down to the best use of my time. Whilst I would enjoy the whole process of building out a design library I really didn’t have that luxury.
ant.design
This one really intrigued me.
I really like their documentation. I really like all the examples they give. It makes it very easy for a developer to understand how to use the components and the options each component provides. They have a long list of useful components. Components like pagination and timepicker were very appealing to me as I knew I would need these in the projects I was working on. It’s also a mature library currently on version 5.
So why didn’t I ultimately go with this library? I think this comes down to very irrational reasons:
- I didn’t know anyone personally who had used it. I didn’t have any specific recommendations from anyone I respected — either someone I knew or an online developer who I respected.
- Gut feeling maybe? Something just didn’t entice me enough to decide to go with this. I had a mass of work ahead of me and this choice just seemed a little risky for some reason. If it backfired there would be some difficult questions I would have to answer.
All in all, I think it would be a great component library and one I definitely intend to use in some of my upcoming personal projects.
Chakra-UI
I’ve actually used Chakra-UI quite a few times on personal projects and I quite liked it. However, I didn’t feel it was the right pick for this project for a number of reasons:
- Style — the overall style, look, and feel of the default Chakra components were just not in keeping with the apps I was planning to build. (Style and design matter a lot!)
- The APIs on the components are a bit limited. If we compare the Chakra Input field with the Mantine Input Field you can see Mantine’s input field has many more props of which some I would use quite regularly. The whole
rightSectionandleftSectionfor me is much more intuitive and easier to use than Chakra’sInputGroupandInputLeftAddonandInputRightAddon
<InputGroup size='sm'>
<InputLeftAddon>
https://
</InputLeftAddon>
<Input placeholder='mysite' />
<InputRightAddon>
.com
</InputRightAddon>
</InputGroup>
It’s a little thing I guess but if I am going to be using a component library for a long project and spend many working hours with it, the little things matter.
So ultimately it just didn’t provide the best option for me.
Material UI
Like many React developers I have used Material UI quite a bit in the past so I was very familiar with it. It has much going for it — it’s got resources, it’s got a wide user base, it’s constantly being worked on and improved, it’s reliable and well-tested and its documentation is really good.
I have to admit, none of these reasons are good solid reasons and that often the case when making some decisions in life. It comes down to a gut feeling which can’t always be explained by cold hard logic.
So why did I not choose it for this big project I was working on? For me, there were a couple of reasons:
- Style — It’s all a bit Googly if you know what I mean. The library is based on Google’s Material Design. Don’t get me wrong, it’s fine but when you build an app using Material UI then unless you do some skilled customisation it has remnants of Google’s designs and that was not what I was after.
- Input fields — I don’t like the input field design on Mui. The input fields are all a bit tall. The app I was going to be working on was going to have many input fields so this was important.
- I’ve used it too much — I think I have maybe used MUI a little too much in the past and just felt like I needed something fresh to use to gain a little inspiration and enthusiasm.
I have to admit that none of these reasons are good solid reasons, and that is often the case when making some decisions in life. It comes down to a gut feeling which can’t always be explained by cold hard logic.
Mantine
My guy was telling me to go with Mantine. I first discovered it when watching one of Jack Herrington’s excellent YouTube videos. I checked out the Mantine documentation and straight away I was impressed with both the layout of the documentation and the extent of components available. It’s also regularly maintained with releases coming out almost weekly.
The default style also appealed to me and from all the libraries I had looked at, this was the style that most closely aligned with what I was envisioning. It has a good range of components, more than some libraries like Mui or Bootstrap and it seemed fairly intuitive to use.
Also in Version 7 (current version as I write this), they migrated the styling to native CSS. It no longer depended on Emotion for styles generation. This is a positive change I feel as it improves performance, reduces the bundle size of the library, and allows using Mantine in environments where CSS-in-JS is not supported. Native CSS has come a long way recently so it’s good it can be used in a library such as this.
It’s 12 months or so since I started using this library and I am still very happy with the decision. The apps I have built with it look really good and I am using many of the components that come from Mantine. It certainly hasn’t disappointed me!
Conclusion
Honestly, in the Frontend world, we are spoilt for choice when it comes to styling our apps. There are so many talented developers making wonderful libraries (all free to use) that we can just import and start using straight away. I think if you chose any of the libraries in the list I started with, you would have a good developer experience and your app would, from a stylistic point of view, look very nice.
I think it’s also important to try out different libraries and not just stick to one. You learn different approaches, you see what works well and maybe what doesn’t work so well and you expand your experience as a developer.
About me
I am a Frontend Developer working mainly with React and Typescript in my day-to-day professional life. I love exploring new tools and libraries and love the Javascript Ecosystem.
I like to write blog posts that share exciting new tools I’ve discovered, how-to articles, and also the occasional opinion piece.
I live in Prague in the Czech Republic with my family.
Check out the original blog post on my blog.