
Design APIs: The Evolution of Design Systems - anthilemoon
https://matthewstrom.com/writing/design-apis/
======
omneity
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.

~~~
jaksawesome
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.

~~~
omneity
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.

------
zackbrown
“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](https://diez.org)

------
hnbreak
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.

~~~
omneity
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.

~~~
hnbreak
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.

------
jlukic
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.

------
treve
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.

