Hot Take: (Re)usable Components
Hot-Takes are quick brain-dumps on practices that catch my eye and my ire.
What’s so great about homogeny?
One of the ideas I see thrown around the industry often is Reusable Components. From the perspective of frontend-engineering/graphic-design/product-design, its meaning is basically:
- Reusable Components
- Pieces of a UI that require a few engineering hours up front, and can then be continually dropped into other pages/applications to deliver the same (or similar) features without further work.
This is, of course, a pipe dream. I’m a firm believer that many frameworks that boast reusable components as a selling point gained their early traction because non-technical users could point to that and make the business case that, hypothetically, they could start spending less on developer hours once every component they need has been created. The problem here is that nearly every new page/app/feature requires a new design that doesn’t perfectly fit with what was previously built. And that’s not because the product designers made a mistake, it’s because value often comes from creating something that didn’t previously exist and hasn’t already been planned for.
Over many years in the industry, I can confidently say that applications that are useful and enjoyable are mainly made of bespoke elements. Sometimes those elements are super similar, but differ in subtle, yet incredibly important, ways. Sometimes those components look almost exactly like another component, but it was found that the other component couldn’t be reused because something behind the scenes didn’t line up perfectly. And to be fair, there’s simply no logical argument that composing your app out of the same reused pieces would make it “better”.
Not to say that no components are reusable, but the attention given to reusable components and the frameworks that support them is completely out of balance with the real world, where maybe 20% of total instances of components come from shared libraries, and everything else is either totally bespoke or a slight variation of an existing “reusable component”.
I think the realistic view is that most components are simply Usable, not inherently Reusable, and there’s nothing wrong with that. They don’t solve every problem that will come up and they won’t work in every possible context that presents itself. Nor should they. Valuable apps need work and attention to detail that the reusability-paradigm simply doesn’t account for.