What is Composability-First Design?
What is the Composability-First Design pattern? Also known as "Atomic-First Design," read along for an explanation and to learn more about how these design principles improve your development experience (DX).
The Why
Building complex components is oftentimes difficult using traditional development and design approaches. In addition to the already many questions a developer has to answer: should I use Vue? React? Svelte, Solid, or Angular? How do I distribute it via a package manager, like npm? Over time, questions like these become exhausting to answer, while trying to find "the best tech stack."
It is interesting to note that this is not necessarily due to the complexity of the development tasks required, but rather due to the sheer amount of moving pieces required to build and engineer truly composable libraries. You may have already asked yourself one or many of the following questions:
- Which code style should be followed?
- Code formatting setup (e.g. ESLint, Prettier, etc.)
- Create a custom, project-specific CI (e.g. GitHub Actions, Circle CI, Travis CI, etc.)
- Automatic library changelog generations upon releases, based on git naming conventions
- Distribution channels setup (e.g. package managers like npm and CDNs)
- Create a documentation site and web presence for the library
- Does your IDE help as much as it possibly could?
No matter which component or function library you are building, these concerns all have to be, and should be, addressed one way or another.
What is a Composable / Atomic Library
Have you ever needed to reuse one of your components from Project A in Project B? Or have you ever needed to access a project-specific function from Project B? How about a beautiful, working modal experience? Or calendar components?
In concept, you can characterize a "composable library" as a collection of components and/or functions that is broken down to its core, in order to be optimized for reusability. This allows anyone to require them (components and/or functions) into anyone's projects.
Think of Lodash for "functions," and minimal HTML for the "components."
How do I know if it's right for me
When wanting to adopt the "Composability-First Design" pattern, you will want to ask the following questions to identify whether or not this design pattern is a fit for you:
- Are you developing a UI component library or a function library? Or both?
- How is the library styled, if styling is required at all?
- Tailwind CSS, Windi CSS, Bootstrap, Tachyons? Or something else, or custom?
- In case styling is required, are "icons" utilized within the UI?
- How is the library distributed across different code bases? npm and/or CDNs?
- Is the library meant to be built for max compatibility?
Both components and functions should be designed with reusability (composability) in mind.
The Atomic Core
As you can see in the "Atomic Design" diagram above, there are two core atomic engines:
- The Atomic UI engine
- The Atomic FX engine
The Atomic UI engine, at its core, is made up of an instant atomic CSS engine, coupled with several UI techniques to ensure the most reusable and composable UI experience. To quote Adam Wathan, the creator of Tailwind CSS:
Maintaining a utility-first (atomic) CSS project turns out to be a lot easier than maintaining a large CSS codebase, simply because HTML is so much easier to maintain than CSS. Large companies like GitHub, Netflix, Heroku, Kickstarter, Twitch, Segment, and more are using this approach with great success.
Much has been written about atomic CSS engines, in particular because CSS is "notoriously hard to scale" (Sarah Dayan of Algolia). If you like to hear about other experiences, check out the following resources:
- By The Numbers: A Year and a Half with Atomic CSS by John Polacek
- The Case for Atomic/Utility-First CSS curated by John Polacek
- Building a Scalable CSS Architecture by Sarah Dayan of Algolia
- No, Utility Classes Aren't the Same As Inline Styles by Sarah Dayan of Algolia
- Diana Mounter on using utility classes at GitHub, a Fullstack Radio podcast interview
Maintainability
Maintainability concerns are a major reason and inspiration for a composable atomic UI/FX engine. When every piece of your stack is broken down to its smallest reusable unit, maintaining and evolving the whole becomes dramatically simpler. This idea became a core reason I started working on Stacks, where composability-first thinking is applied to the entire framework, not just the UI layer.
If you have any questions or comments, feel free to reach out on Twitter or via email.