| For the past few years, i’ve been building “reusable component libraries” and I can say with confidence that they’re a massive waste of time. When you get into it, the UI usually the least difficult problem to solve in an app. The real challenge is state management, control flow, and wrangling sode effects. Alas, people are still wedded to the idea that UI is where all the time is wasted. The truth is, it’s always been easy to put a button on a screen. But making that button do something? That is a much bigger problem. I’d argue that 99% of the effort of putting a button on a screen goes into implementing whatever that button does. But stakeholders don’t understand that. They think buttons just do the thing they do, so when it takes six weeks to put a button on screen, they naturally assume that a reusable component library that includes a button will somehow shave days and weeks off a project. Which is why they gravitate towards UI libraries. And then they introduce a new problem that wasn’t there before. They want us to use Material UI, but they want us to make it look different. And they want a bunch of extra UI elements to boot. So not only do we still have all the original problems of creating an app, we’re now on the hook for turning some implementation of Material UI into something that fits with with our architecture, but is also completely different. So while I hate UI libraries, I recognise that they’re something inflicted on a team. So I’ve started work on a UI library designed specifically to address this problem. It’s a UI library that’s meant to be changed and easily customised by it’s consumers. It’s minimal functionality and minimal styling. I’ll announce it here on HN when I think it’s ready. It may never be ready because not only is it a difficult problem to solve, I’m also very lazy. But anyway, I say all this because I hear what you’re saying, and I’m working on it. |
[0] https://twitter.com/olivtassinari/status/1120818781058686979