I’ve been working with web styleguides and now design systems for years. I created MDS for Mavenlink, and EDS for Ethos, and many other professional experiences building web styleguide before. I once created the most popular Sass Buttons library on the internet with my friend Alex Wolfe. I’ve used Bootstrap, Foundation, Material, etc., and I’m fairly aware of how things are working in this ecosystem. Well, I think it’s all a bit broken…
Issues in the UI Component World
After feeling quite pleased with myself for creating a design system out of thin air quickly at my last role at Ethos, I started to introspect. What the hell had I just done! I created a design system full of UI component primitives completely coupled to React! Yet again! What was going to happen when I went to my next job–was I really going to create a whole ‘nuther set of component primitives from scratch because they used Vue, or Svelte, or some other framework? Was my HTML, CSS, and design sensibilities just so good that it was worth creating a custom framework yet again?
I justified all this with the idea of how a company with a vision must have it’s own identity and brand, and that having custom branded components is just the best way to go.
I do still feel that way to a certain degree. While I appreciate the amazing achievements of something like Bootstrap and can appreciate the fact that you get a lot of bug fixing for free when you use a framework like that, I would generally not want to be at the mercy of their aesthetics and choices. I’ve played the whole CSS overrides game and it’s not a pleasant experience and degrades performance since you essentially need to write extra CSS to fight Bootstrap (or really any other framework that’s not somehow super configurable).
What are the biggest issues with Design Systems and UI Components today?
To my mind:
- design system tooling: Storybook is great for authoring but limited for custom publishing needs. react-styleguidist is tied to React! I want a way to be able to author and publish without having my design system look like Storybook or react-styleguidist. I’ve bent react-styleguidist to will in two design systems so it gets my vote for publishing between the two, but it’s still a bit of a fight.
- Syncing: design system implementations go out of date or do not reflect the Design and UX department’s intent.
The Syncing issue is quite hard. I saw a beta app that I can no longer find that was purporting to generate React components from your Figma components (or was it Sketch symbols?) and I signed up for when it was released but never got a chance to try it. But, even though it’s great that you could generate a React component from your design files, there are a couple of problems. First, it’s still tied to React which makes me sad. Second, have you ever fought generated code? It sucks. Invariably, you have to hand edit the generated code. In this case, that might defeat the whole purpose I dunno.
Of course the flip side is you do get a lot in terms of the “batteries included” aspects of using something like Chakra. I didn’t mean to pick on Chakra btw, Material-UI and many others do this too.
HTML and CSS
tailwind.config.js file that, essentially, defines a theme configuration to your liking that will result in its utility classes matching your preferences as such.
Why not do that for our UI component primitives?
For example, let’s say I have a structure for a button component that lives in
<root>/components/button/* and looks something like this:
├── buttons.css ├── buttons.html ├── react │ ├── buttons.jsx │ └── buttons.module.css ├── svelte │ └── buttons.svelte ├── vue │ └── buttons.vue └── web-components ├── buttons.css ├── buttons.html └── buttons.js
buttons.html files would be considered the core and pristine versions of the button primitive. Once these core definitions are defined to satisfaction, examples in various frameworks could be added. Obviously, this is just a sketch and the directory structures could be optimized to however the ecosystems deems best. But the idea is that you’d have core HTML and CSS driving your presentational primitives, and any “framework specific examples” would be a secondary result.
One pain point above is that if/when we change the core
buttons.css files, we’d need to somehow sync all the framework example components based on them. I do not yet know the solution to this problem.
Conclusion and Concessions
My idea only solves one of my complaints from earlier–the framework agnostic problem. How we port these into a design system and publish them to match our brand and also stay in sync with our Design team remains to be seen. I think that’s really a tooling problem and my hope is that this would be handled by a tool that also fixes my other complaint of custom publishing. I suppose I’d like to see the best of Storybook and react-styleguidist combined into a single powerful and flexible tool. But, perhaps that’s a pipe dream I dunno.
If we can at least author agnostic components that aren’t tied to a framework, that would certainly feel like progress to me. I may just start to experiment with this myself. I’ll need to have “mini-build projects” for each framework example to pull this off. But, I think similar to TodoMVC, it’s quite possible. Perhaps if my experiments show promise (and I stay motived haha), I could create an RFC and see if I could compel the community to get involved. We’ll see ;-)Subscribe to Newsletter