Buttons are one of my favorite components. On the surface they seem simple, but in practice, they tend to be much more involved. In a post by Nathan Curtis entitled And you thought buttons were easy?, he demonstrates how costs can quickly skyrocket to $1,000,000 when one arm of the organization isn't aware of what the other is doing.
This is easy to brush off as an extreme example that only applies to really large companies. But how much does a design system actually cost?
A Real Life Example
Before joining Microsoft, I did a short stint at a company with more than 10,000 employees. I was on a dedicated design system team that included five engineers, four designers, and two design technologists. Over the course of 12 months, they had built about 30 components for their design system.
Many of those positions paid six figure salaries, and that doesn't account for benefits and HR costs. Let's pretend the average salary for each position was only $100K USD. That's 11 FTEs working for a year, totaling $1.1M in salaries. Again, this doesn't include stock grants, health insurance, and additional benefits.
All that to build buttons, dialogs, form controls, tabs β nothing proprietary. Just every day components that have been built many, many times before.
The Cost of Frameworks
I forgot to mention that the components they were building were for React, which means that only React teams can use them. As a result, either the entire company must agree to use React or non-React teams will have to duplicate effort by building the same thing in their framework, running the price up even higher.
In large orgs, these costs tend to fly under the radar, but they're tangible expenses if you know where to look.
Many design system teams I've spoken with are rebuilding or preparing to rebuild "legacy" design systems. The story usually goes something like "we're phasing out Angular 1.x" or "we're evolving from a Bootstrap-like design system."
And a lot of them want to build in React.
This leads to more costs that aren't being realized. Just like jQuery dominated the front end yesterday, React dominates it today. There will be something new that dominates it tomorrow. Your design system team will continue doing the same work and incurring more and more costs to keep up with framework churn. And let's not forget the cost of updating tomorrow's legacy apps, who are consumers of your soon to be legacy design system.
The Platform Outlives Frameworks
A modern design system's component library β the foundational elements from which all your apps are built β are excellent candidates for Web Components: a standard technology that's built into all modern browsers. Web components are used by some of the world's largest companies, including Adobe, Amazon, Apple, Ford, GM, Google, Microsoft, NASA, Salesforce, SpaceX, Visa, and many, many more.*
If you care about longevity and cost, the platform is simply a more logical choice because browsers have committed to supporting Web Components for a long time.
It's astonishing to me that so many engineers fail to see that doing the same work over and over again isn't productive nor cost effective. How many times do you have to rebuild a button before you think "maybe this isn't the best way forward?" Imagine how much more productive an organization could be if those design and engineering hours were spent elsewhere.
Now imagine if you didn't have to build all those portable UI primitives yourself. What if you could just apply some of your own styles and start building patterns and apps? π€
Jump Starting Your Design System
Every design system is different, but how much would you save if you could kick things off with a solid set of accessible, well-tested components? Imagine not spending $1,000,000 on buttons. Imagine jumping right in and building more useful components for your organization. Imagine telling your engineers to use whatever framework they want because it will work just fine with your design system.
That's one of the reasons I built Shoelace, an open source web component library that serves as a design system starter kit.**
Shoelace solves real world problems by offering accessible, intuitive, and interoperable components that save teams and individuals tens of thousands of dollars or more. It's totally free, by the way, although sponsorships are always welcome.
There's no need to roll your own buttons anymore.
*There's a longstanding misconception that Web Components aren't ready for mainstream consumption. This is a stale argument that held more water many years ago when the standards were less mature. These days, companies such as Adobe are embracing Web Standards by migrating flagship products to web components. Web components aren't just ready for mainstream β they are mainstream.
**One of my followers told me they didn't want to use a third-party library as a basis for their design system. I suggested they fork the project if they want to have complete control of it. Their reply was something like, "but then I have to maintain it myself!" That argument wasn't well thought out, because you'll still be maintaining it yourself if you build it from scratch!
Top comments (5)
But Shoelace still is YAD - Yet Another Dependency. Just like the other 55+ BaseClasses that compete with you.
If a BaseClass is updated everyone using it has to retest their code. In a recent update Lit made a breaking change.. everyone called it minor, but at the end of the day it was a breaking change.
The only way to prevent that is to make ALL code Your Own Code. Create your own BaseClass, disect every "competing" BaseClass and apply it to your own code.
So basically I do not trust developers who say: Web Components are great I created a way to make them easier and you should use it. It totally goes against What Web Components are. Its like saying: This is how I use
Map
, and you should use it like I did.PS. Good Luck in the Microsoft world, spent 15 years in it, and left when they switched (SharePoint FrontEnd Development) to React.
I've spent years of my spare time building Shoelace. Good luck rebuilding all of it on your own with the same level of features and quality in a timeframe that's acceptable to your employer. It's not an easy undertaking. And even if you build your own, you still have to maintain it!
The difference is, with open source, you get free bug fixes, new features, and more eyes on the project to help test and report problems. I don't understand the fear of using selective dependencies. It's poor judgement for any type of engineer and akin to "I don't want to rely on a factory to send me metal tubes so I'm going to extrude my own aluminum instead!" It's silly and wasteful.
With open source packages, you get a ton of value for free and if the project becomes misaligned from your needs, you can fork any version and choose to own the code yourself. What's the difference in maintaining your own code base vs. an open source one? And "I built it" isn't an acceptable answer unless the code base in question is very poorly designed.
Some people build their own houses. Some people make their own tomatosoup. Silly and wasteful
Know your history, Gory, dependencies, NPM, any code that is not your own, sucks:
How one programmer broke the Web, by deleting 11 lines of code
How Mootools broke the Web (even React)
You asked: What's the difference in maintaining your own code base vs. an open source one?
With Open Source code you will wake up one day to a reality described in the above blogs.
It is not if, it is when.
My own code gives me 100% control, any mistakes are my own.
That is also the reason why I stick the UNlicense on all Web Components I make Open Source.
I don't want to maintain dependencies.
BTW, Why are there 50+ alternatives to your Shoelace? And why do you think the stuff you built in your spare time is better than what the Lit/Stencil/Whatever team produces?
Let me emphasize my previous statement: "you can fork any version and choose to own the code yourself"
If you don't see the benefits of open source as benefits, it can still be a good starting point that you can maintain yourself thereafter.
I can agree to disagree, though. βοΈ