Six reasons why we build our own UI components library from scratch
Using open-source libraries to build your application is a great way to move quickly and keep your team focused on building core business logic. Most applications do this, but is it really the best choice for applications that protect companies’ most precious assets? Here are six reasons we made the choice to build our own UI components library.
1. Flexible 🤸🏽
Using our own libraries gives our product and UX teams complete freedom to choose the right component behavior — something that’s not available in most UI libraries. Just as designers tailor design systems to the product, creating our own libraries allows us to do our job in the way that’s best for the business.
2. Patch-free 🩹
At first glance, using a premade UI library may seem like a fit with our needs. But there’s always that time when we need to change something that we’re not able to via the API. That means we have to write a patch to fix the issue. But the more we do this, the more we are in the business of writing and managing patches, and the code becomes too hard to maintain. Making things worse, third-party libraries often expose these customization library configs in a patchy-big-json configuration.
3. Ownable 💪
Having our core components library built in-house gives our developers confidence that we OWN what we do, and enables them to stand behind our application in production.
4. Familiar 👋
By maintaining consistency across our entire code base, we can ensure the same code style enforcement, utils, build process, and more, so there’ll be less friction for new developers going into the code base.
5. Fun 🤓
When you write complex UI components, it makes you dig deeply into the APIs of the tools you use daily. This will make your whole code base better. Not only the library. And if you love frontend then… It's fun! You won’t get a chance to work on such a challenge every day.
6. Secure 🔒
Four out of five code bases containing open-source components are vulnerable, according to Lawfare. By controlling our own libraries, we can ensure the security of our platform — and remediate issues in Dazz.
Instead of using a complete premade UI library, we chose to use atoms-level libraries like “vue-use” composables, which provide many many useful utils, “date-fns” that provide perfect utils for our set of date-picker components, and a few more libraries.
All are in the utils / atoms level of code to leave us with the complete freedom to move forward in a flexible, patch-free, familiar way that we own 100%.
