Design APIs: The Evolution of Design Systems | Hacker News Reader

Design APIs: The Evolution of Design Systems

matthewstrom.com

84 pointsanthilemoon11 comments

This article was pretty confusing.

At one point I thought the main thesis was to take inspiration from software APIs to document the process between the design and development team, which already looked like a pretty horrible proposition, taking Anti-Agile to a new extreme in the Individuals and Interactions vs Processes and Tools spectrum.

But then ... I just got lost.

So is the idea to build a REST API to serve constants of a design system, such as colors and font sizes and have a single reference point?

Design tokens and standard formats seem to go in this direction, but honestly this seems like one of the last problems to solve, in the Design System space.

Please someone enlighten me if I'm misled somehow.

I think you're right about this.

In fact, I think the API ecosystem would be better served by trying to take inspiration from design teams to provide more standardized, compliant, and good-looking interfaces.

Exactly, that looks like a much better cross pollination.

I was secretly hoping TFA would talk at one point about API design and leveraging design systems to bring uniformity and consistency to software APIs.

That would have made for a much more juicy proposition.

Design System teams need to stay busy after they exhausted the 17 different ways to redesign a toast notification that still only serves 10% of the product needs, and management needs a roadmap for next year.

“REST for design tokens” is alluring because it’d be codebase-agnostic, but it would be incredibly risky & maintenance-intensive.

Design tokens evolve. Builds would break when schemas change—or if you hacked around that you’d forfeit the advantages of typed languages on iOS/Android. Untyped Javascript/CSS would silently break and start to decay the minute changes are made on either side of the server.

There are ways to wrangle “single reference point” for design tokens without introducing a network dependency.

See the open-source project Diez, a polyglot native transpiler for design tokens. (I’m a project maintainer)

https://diez.org

IDK about the article but in this context: Atomic css, in particular Tachyons, paired with React is one of the fastest ways to create gorgeous and consistent designs.

Have you tried tailwind css before? It's a similar philosophy to Atomic but slightly higher level (similar to Tachyons) more opinionated, and potentially even faster to develop with.

Yes, I tried tailwind few times but I'm 10x more productive with Tachyons: tailwind doesn't make sense from my point of view. It wants to be atomic css but has way too long class names, they're so long I could also use normal style declarations in object notation; then it's not as intuitive, the setup is cumbersome and then it's not a real design system like Tachyons is. E.g. Tachyons' chosen units are super thought-through--you can't make bad designs. So, after this, I got back to Tachyons and never looked back. Still I think it's good to see another contender because atomic css should be the standard and the more players the better.

Thanks for the tip! I’m a backend/systems engineer and this is exactly what I need to make functional frontends when I have to.

I think the confusing thing here is the use of the term “design token” to mean variables/constants used for css theming.

I think they need this jargon to make it seem like something more novel than the well established practice of storing css constants as theming variables—something OSS UI component libs, or even wordpress, has been doing pretty well for a long time.

If you're building an API to provide these constants, why not take it one step further and use text/css instead of application/json.

Reply on news.ycombinator.com