The “normal” workflow I’m sure we’ve all lived is that design happens, then coding happens. A healthy workflow has back-and-forth between everyone involved in a project, including designers and developers, but still: The code is the final product. You design your way to code, you don’t code your way to designs.
It was only a little over a month ago when it was news that Sketch 43 was moving to a .JSON file format. The final release notes drop the news quite blasé:
Revised file format
But Jasim A Basheer rightly made a big deal of it:
… it will fundamentally change how the design tools game will be played out in the coming years.
“enables more powerful integrations for third-party developers” is stating it lightly. This is what the fine folks at Bohemian Coding has done — they opened up Sketch’s file format into a neat JSON making it possible for anyone to create and modify Sketch compatible files.
“Interesting.” I thought to myself. “It’s like an API to a design document. I wonder how this will play out.” Little did I know just weeks later we’d see a really powerful tool drop.
… share a tool we built to help bridge the gap between designers and engineers working on design systems at scale. React-sketchapp is an open-source library that allows you to write React components that render to Sketch documents.
It’s worth embedding one of their videos here:
Coding your way to design documents! Which makes more and more sense, as design tooling and code tools converge on concepts:
In Sketch, we use symbols and overrides, in React we use components and properties. The concepts are so similar that it seemed silly not to unify them.
We also wanted to minimize sources of truth. Why keep a separate library of components drawn by hand in Sketch once we have them implemented as the real thing used every day by millions of people?
The fewer sources of truth we have for a design system, the more efficient we are.