14 May 20242 minute read

On Constraints and Freedom

lessons learned from component styling APIs

One API mistake we (I) made with Canvas Kit was providing multiple ways to style components. Shortly after I joined the team, we began testing various styling APIs for our text components. Teams had very strong and differing opinions about how to style things — styled function, object styles, style props, etc. We took that feedback to mean, “Strictly enforcing a style implementation hinders teams. We should let them choose how they want to style UI.” My go-to line became, “We want to help you be productive, not tell you how to be productive.” Sounds good, right?

Well, no. It's a mess.

Let that trend run for a few years and you end up with teams styling in all sorts of nonsensical ways. Styling patterns were combined in a variety of ways without much understanding. Providing freedom with little guidance on why created havoc for us and teams.

At the same time, the styling landscape was changing drastically. We saw the future was making CSS first-class again, but we also couldn't make a hard break and leave teams stuck with a painful migration. We needed a solution that unified how we style UI and would also nudge us toward a more CSS-first approach.

In Canvas Kit v10, we began pairing that back by introducing a singular styling solution, Stencils: an object-based styling solution that can avoid Emotion's runtime cost. It's familiar enough to what we used before, but opinionated enough to help make good decisions quickly. It also helps decouple styles from component code; pushing us toward a more CSS-friendly mindset. At first we thought Stencils would mostly be useful for our team internally. We made everything backward compatible and opt-in only. But we were surprised to find most teams wanted to use it as well. They wanted to reduce the cognitive load of choosing between patterns.

A significant factor here is our wonderful developer community who really trust us to get things right, despite our occasional mistakes. None of this would work without them. And I am incredibly grateful. 💜

But what happened to all those strong opinions from our research?

We (I) mistakenly assumed that freedom of choice was a greater factor for productivity than time-to-decision. Having the ability to choose is great but also mentally taxing. Built-in choices reduce the mental cost, helping teams move forward. Ultimately that's what wins.

The art of this job is getting the constraints just right. You find a sweet spot where you're not blocking productivity; you're channeling it into something powerful. You reduce friction just enough so teams forget about your tools and focus on what they're creating.