Painting with Code: Introducing our new open source library React Sketch.app | Hacker News Reader

Painting with Code: Introducing our new open source library React Sketch.app

airbnb.design

787 pointspouwerkerk95 comments

Basically, people:

• Design a set of re-usable components in Sketch that get turned into JavaScript widgets and used in a product

• The JavaScript widgets are are modified, extended, and changed. Maybe a line here, a color here. Designers now sometimes have component designs don’t quite match what they look like in the wild

• This tool now lets them re-create the Sketch file from the components as the look in the wild. That means when designers work on whole pages, made up of widgets, they’ll look exactly like they would in the wild.

Often it takes a third party to succinctly describe a software technology.

The website doesn't explain it like this.

to complete the explanation, sketch is a vector-based design tool that has an api for scriptable generation of components. this library lets you generate sketch widgets from react code; i presume that those widgets are then higher-level shapes stored as single entitles in sketch, so that when you update the react code, sketch files that use those components now use the updated versions.

also, from their faq, there is no two-way binding; they do not attempt to extract react code from sketch files. the idea is that the react code is the source of truth.

from a programmer's perspective, sketch is sort of like an exploratory repl where you can play with bits of code (widgets here), composing them into larger functions (sketches), and when you're satisfied with the design you edit your source file and reload the state of the repl so you can continue exploring.

Thanks, that helped :)

I think this is pretty cool. I might even update my React install and check it out properly

Can someone elaborate on the programmer's perspective? I understood the first and second paragraph (super helpful thanks!) but the exploratory, reloading repl escaped me.

let's take a concrete example. say you want to write a ruby program to scrape some information off a website (e.g. crawl imdb and get a list of the top 100 movies and their stars). so, how would you go about it?

well, first of all you want to download a page. you haven't done in a while, so you google up the relevant ruby library (open-uri) and install it. then you load it up in a repl, like so

irb> require 'open-uri'

=> true

irb> url = 'http://www.imdb.com/title/tt0093779/'

=> "http://www.imdb.com/title/tt0093779/"

irb> page = open(url).read

# lots of html

now that you have confirmed it works, you paste it into your program

require 'open-uri'

def get_movie_html(id)

  url = "http://www.imdb.com/title/#{id}"

  open(url).read

end

then just to confirm it, you go back to your repl, load your file and try

irb> page = get_movie_html('tt0093779')

you have now not only written the first part of your program, but it is available for you to use in your repl as you figure out the other bits. as you get each part working properly, extract it into a function and add it to your source code, then reload the source in your repl and continue working.

the main idea is you get very fast feedback about the specific bit of the program you are working on; the repl maintains the state of the data for you, so you can probe at it till you have ironed out the issues, and then once it is in its final form you add it to your concrete code and use it as a building block in the repl.

here's another blog post about it: http://www.davidtanzer.net/rdd_and_tests

the analogy with sketch and react is that similarly, you can design a component (say a top navigation bar) in sketch with a very fast feedback loop, and once you are satisfied with it, you reproduce it in react and then reload your sketch environment from the react file, so that from now on the navigation bar you see in sketch is the exact one you have built in code, and you can use it as a building block for the next part of the site.

REPL (Read-Eval-Print Loop) is an interactive way to program. You feed bits of the program line by line, in contrast to compiling a bunch of files. This is kinda like giving instructions live vs writing down a list beforehand.

When solving some problems, it's easier and quicker to use a REPL to get something that more or less works, and then to copy the working bits over to a proper source file to reuse. Before this React Sketch, Sketch.app was just the equivalent of the REPL, where you'd only store the result of your work, and not the process. Now you have a way to, as soon as you're happy with a design you drew by hand, write the code to generate it in order to reuse it in the future.

Hi HN!

Super excited to open source this — I'm trying my best to bring design & engineering closer together at Airbnb (and in the world), this has been a super useful project.

I'll be hanging out in this thread all day if you have any questions / want to flame me :)

Can you explain a scenario where you would use the resulting Sketch file? I still don't quite get it (probably as not familiar with React)

The initial usecase we built it for was generating templates for our design system (color palettes, components etc). At our size, keeping them in sync with the production state-of-the-world was super difficult. So we scripted it, using our production components.

It also led to some exciting new uses:

- component pickers / editors for Sketch that are backed by real components rather than Sketch symbols (build your own UI)

- automatic accessibility checking / internationalization

- using real data in Sketch with real GraphQL queries etc

- as a building block for using Sketch as a canvas for the design tools of your dreams, whilst maintaining compatibility with the tooling your designers use today

> automatic accessibility checking

Can you elaborate on the automatic accessibility checking? Are you testing the sketch file or the react-primitive code for accessibility tags?

e.g. checking accessibility of colors in a UI :)

OK, like detecting lack of contrast for color blindness?

Sounds intriguing, but I'm also a little confused about the flow of "code that generates sketch files"... what is the purpose of Sketch in all this?

I would think programs like Sketch are useful in general because they give designers a nice way to design things without adding the extra layers of abstraction that code brings (i.e. they can just draw things with a mouse instead of writing instructions that tell the computer how to draw things). But if Sketch is just another rendering layer of react components, then what is the point of having it... why not just look at the rendering in a web browser?

Or am I misunderstanding and there's a way for react code to be generated from Sketch? (Despite this statement in your blog post: "As the industry has coalesced around Sketch, people have sought to generate code from Sketch. This is exciting, but for our challenges we wanted to do the exact opposite — to keep DLS in sync we have to generate Sketch files from code.")

i assume they want to have only one "place of truth" which should be code. The designers can generate the skethfile of components and then use them in their layouts (eg usecase core components)

also it opens up things like "using real (suboptimal) data" or cross-project-wide refactoring of design, etc

Ah, this makes sense (assuming this is what they're saying).

So there would be one sketch file for the basic components that is generated from the React code, but the designers who design specific pages of the site (for example) would still design in sketch, but pull from the components of the one "read-only" (react-generated) sketch files. Very cool!

Exactly (and thanks to Andreas for explaining it better than me).

We have a design systems team that creates & maintains the system (in collaboration with our product designers), resulting in read-only Sketch templates. when _designing with_ canonical components our product designers are using that template, so it's kind of the same workflow - we're just creating the read-only templates from code rather than by hand.

So your design systems team has to be able to code React components, or any change or new component has to be coded by a developer before being made available to your product designers?

If so, does is not lengthen and complicate a lot your design process?

Would be fantastic to add a section to the blog post and project README with a quote like this

> the designers who design specific pages of the site (for example) would still design in sketch, but pull from the components of the one "read-only" (react-generated) sketch file

Maybe under a "why use this?" heading?

"why not just look at the rendering in a web browser"

This is a good question — I’m a technical-leaning designer so I’m partial to just using browser-based tools. I think things like Deco and Expo Snack are wonderful.

That said, I’m specifically looking at improving the efficiency of designers’ workflows without changing them. My team is part of DesignOps at Airbnb, maybe useful to consider it analogously to DevOps. ~= “We’re changing the servers that our applications are deployed on without forcing our engineers to learn a new language”.

Anyway, 1) having Sketch templates always-in-sync with real components is huge, 2) we’re building custom UIs on top of Sketch to use those components (which we may open source eventually), 3) this is a baby step to get us to the point where component-centric tools like Deco and Subform are good enough to realistically switch our design team to.

So... basically this entire system is really just a way to render React components in the Sketch App? And any changes to the design cannot be made in the sketch app, but instead must be made in React code? (So Sketch is just a "read-only" tool?)

It's a library of design components generated by in-production code.

In theory a full design system has most individual pieces defined. You know what your button styles, inputs, headers, etc are and designing new layouts is often a matter of rearranging these various components — you'll occasionally need to design new ones, so that's the outlier here.

This ensures designers are using a single source of truth when it comes to existing components (which is pretty spectacular, because traditionally designers often maintain an overlapping library of static components for design purposes). It also helps hugely that I could pull in real data instead of trying to transpose some real-ish information into a static mock-up.

And of course there's still that design/developer grey area. I'm educated as a designer, but I'm extensively knowledgable about HTML/CSS/SASS — and that still only takes me so far. I know basic JS, but I'm not going to pretend that I can use React. Sometimes I still need to build static mock-ups so I can try out animations or storyboard userflows, do usertesting, etc.

To go the other way -- generating React code from Sketch -- you can use React Studio:

https://reactstudio.com

It has a Sketch plugin that does a rather competent job of converting Sketch layers/groups into components. (For example, you can prefix a Sketch group with "c:", and React Studio will interpret it as a component.)

Here is a live video demonstrating the Sketch -> React Studio -> React code workflow: https://www.youtube.com/watch?v=Rfd7zmlFZw8 (It's in realtime with detailed explanations, so it runs about 40 minutes.)

Disclaimer: I wrote a pile of code for React Studio.

Interesting. But, the monthly Adobe-esque subscription fee is a turn off.

That is of course something that can change. What kind of pricing would you prefer?

Any kind of one-time pricing would be great.

Ideally, with a perpetual license with 1-year of free upgrades.

That seems definitely possible. I think what the team was worried about is sticker shock -- $19/month might translate to something in the region of $200-250 for the scheme you propose. Does that sound bearable?

Thanks!

yes!

perpetual license is what scared me off as well. Ideally $199 with 1 year upgrades. As long as it keeps working after 1 year I am sold.

It seems like the logical conclusion is to create a two-way data binding in a live-coding environment.

The idea behind React Studio is awesome.

I think it would be super cool if React Studio could automatically create a GraphQL api based on the structure of the component data.

We are already doing small experiments in this direction at Graphcool (for example graphql-up https://www.graph.cool/graphql-up/)

Do you think anyone at Reract Studio would be interested in talking more about this? They can ping me at soren@graph.cool :-)

Sounds really great, I'll pass on your contact info!

If reactstudio could support loading in react form, components, color themes etc al from the hundreds of react themes sold from places like envato, themeforest, etc. then a whole class of UI mock ups could be built. Example themes:

https://themeforest.net/item/material-design-reactjs-admin-w...

https://genesisui.com/demo/?theme=prime&version=react

Hello, I work at Airbnb and helped Jon with this project a bit.

A lot of people when they first learn about this project have a hard time understanding how it would be useful - so you're not alone!

I tweeted ([0]) about this briefly and thought I'd copy here for the benefit of readers in this thread:

> the wild thing about react-sketchapp is that we can now bootstrap designs with the actual code that powers the product we are designing

> it took me a little while to realize the paradigm shift. we normally think of the code / implementation as the end of the process

> this allows us to use production code not only for our production clients, but also for starting the next iteration

> react being decoupled from the underlying UI implementation unlocks a lot of possibilities. this is just one.

> we are starting to view our react components for our design language as not just an implementation, but as the specification itself

  [0]: https://twitter.com/intelligibabble/status/856941689029640192

mind blown

This is exactly what I'm doing with Semantic UI React. I'm prototyping in React, and building my own visual language on top of the visual language of Semantic UI. I see how I could instead render my components to Sketch instead (if a really great Sketch file with all the Semantic UI components existed).

Thanks!!!

How was React Sketch.app influenced by your blog post from June 2016: Declarative Design Tools (http://www.jon.gold/2016/06/declarative-design-tools/)?

So for context that was written whilst I was funemployed before joining Airbnb.

- René etc is more conceptual - it’s obviously not a practical day-to-day tool

- React Sketch.app solves the problems in our org that I can do something about, but also lets you do combinatorial/permutational exploration (see the GIFs in the intro!) because _it’s just javascript_.

Both embrace the paradigm of UI-as-a-function-of-data, and really are indebted to the mark that Guillermo left on my brain with https://rauchg.com/2015/pure-ui

Thanks for the link

To help clarify why this is a big deal, I'd like to share why I've been so excited about this project...

[tl;dr] - This is the first tool I'm aware of that actually allows you to generate both API docs and design tools from the same source.

Static documentation is a lie waiting to happen. Once docs are even slightly out of date, people lose trust and eventually abandon them.

On the engineering side of the dev/design process, this is easy to work around. We generate documentation from code and structured comments, which allows us to trust our docs as an up-to-date point of truth.

If you're building a design system that both engineers and designers will work with, there's no real solution to keeping sketch symbols and React components in sync. You're essentially stuck maintaining "static documentation" for designers in the form of a sketch file.

More often than not, things get busy, or someone forgets to commit a change to the sketch file, and the sketch symbols fall behind the code used in production.

Developers start to receive mocks that don't match the "standard" components they're using. Designers start to wonder why fidelity is lost by the time features make it to production. The design system falls apart.

`sketch-reactapp` will help us deal with the static documentation problem the same way we deal with it on the engineering side of things: generate from source.

This is the first tool I'm aware of that actually allows you to generate both API docs and design tools from the same source.

Congratulations on the launch!

That seems like it has some value for super large teams. I guess the thing I'm having a hard time wrapping my head around is the workflow for a tool like this. My current understanding is that you'd need:

1.) Design your thing in Sketch

2.) Code your thing in a text editor

3.) Port your code over to this new tool to see it rendered in Sketch?

Like I said. There's some value there (accounting for the changes between 1 & 2), but the workflow feels weird. Maybe someone from AirBnB design can jump in and enlighten me.

Yeah this confused me as well, but some other comments here clarify the situation: there's one sketch file that is the "design system" (containing the "components"), then a bunch of other sketch files for the actual pages of the site or screens of the app... it's only this "components" file that is generated from code. Sketch is used for the design of the pages/screens/etc, but they are pulling the components from the "design system" file.

As with most misunderstandings/disagreements/arguments in the programming world, this confusion arises from people in different contexts using a tool for one purpose, but not realizing that other people are in different situations trying to achieve different goals with those same tools.

(Specifically, if you are an agency or freelance designer/developer, and you are building a bunch of different sites, then this tool does not serve any useful purpose... but if you have an underlying "design system" and a large company with lots of different products all sharing the same basic design, and a large team to go with it,then this starts to make a lot more sense.)

I work on the design system side. In size of Airbnb, you need some kind of design system, since the product fairly large, its changing every week, it's built for 4-6 platforms at the same time by dozens different teams and designers. Without a system the product design and therefore the product becomes chaotic and inconsistent over time.

I do think that design systems can be helpful for smaller, or even 1 person teams as well. It helps you to apply meaningful constrains for your design and reuse common components across the product to shorten development times.

With the library we have both designers and developers can construct completely new views or modifications fairly fast. https://twitter.com/karrisaarinen/status/849733176150773761

Where the React-Sketchapp comes in is help us to keep the system up to date for designers, and in the future build other tools that can help the design workflow.

> This is the first tool I'm aware of that actually allows you to generate both API docs and design tools from the same source.

Where are your API docs coming from? When you say "the same source", is this because your frontend/backend code is sitting together in a mono-repo?

Not familiar with the AirBnB architecture so I'm interested to know how API docs are adjacent to this topic.

This is super cool - I see designers struggle with this at every company and am a huge fan of tooling that make design/eng collaboration better.

Hi Jon. Any plans to extract interactions as code from modern prototyping tools (e.g. Principle) to Xcode?

AirBnB recently released Lottie that requires After Effects but when compared to Principle, AE feels like Photoshop compared to Sketch. I have a feeling that not many UX designers on Mac want to go back to Adobe tools. Certainly, I don't want to touch Adobe tools again.

So, to be clear, a month ago there was an announcement about an app called Sketch (renamed to Snack now apparently) that was a playground for React code, but people said it was a bad name choice because Sketch is already a ui/ux dev/design tool in this space.

But this tool is related to that ui/ux version of Sketch (but with/for React), and not the mis-named Sketch (that was for React)?

Naming is fun.

Yup. We were aware of the Expo issue, and thought about renaming it, but looking at the landscape of React renderers —

- react-dom

- react-native

- react-vr

- react-hardware

- react-blessed

- react-three

- react-aframe

etc

it felt like the right thing to do was a descriptive "this is what it is" name rather than a "marketing name" that would be more confusing.

So, to be clear

Yeah, about that.

Are you saying that the "React Sketch.app" in the title is/should/will be "React Snack.app?"

no.

i'm hopelessly lost

Snack - Description: Web-based react-native playground. Snack was previously called Sketch which led to much confusion. - Built by: Expo

Sketch.app - Description: Most popular native mac app for designing UIs - Built by: Bohemian Coding

react-sketchapp - Description: Convert a UI written in react-primitives to sketch. react-primitives is a subset of react-native. - Built by: Airbnb

I want to say Snack has nothing to do with react-sketchapp, but unfortunately they do share a couple of things. The developer/user of both tools will write code that is largely compatible with each other, basically a shared subset of react-native. Then, there's the whole confusion with the name Sketch. Snack used to be called Sketch. react-sketchapp uses "Sketch.app" as a rendering engine and editing interface. "Sketch.app" is basically the next program in the workflow for the user of react-sketchapp.

For anyone missing context, naming is hard.

https://blog.expo.io/expo-sketch-expo-snack-a444f8dec72b

its not hard, just don't name a new design app after an already existing one.

Do I understand the use-case correctly ? :

1) Create designs in sketch (mainly core components)

2) Code those designs in React that will generate the React translated version of the sketch

3) Use the react generated sketch to build non-core component designs in sketch . .

4) When the core design changes, update the react component to match the new designs

5) All the other components in the sketch will automatically start using the new updated sketch component

This is how I understood it as well

This is how I'm starting to understand it as well but it took a lot of reading comments here and in Designer News to get there.

Here's my variation:

1) Using a text editor like Visual Studio Code, write core components in react-primitives. This code can be largely the same as your real react-native code with all it's handling of layout and internationalization.

https://github.com/lelandrichardson/react-primitives/

2) Create a library of core components. In aggregate, this library is your DLS (Design Language System)

http://airbnb.design/building-a-visual-language/

3) Use react-sketchapp to transform your core components in react-primitives to sketch symbols. If you have a large design system and support multiple languages, then this will save you a lot of time as the number of combinations of layout, language and potential input values are explosive.

http://airbnb.design/painting-with-code/

4) Use sketch to design your new feature. Use sketch symbols to quickly pull in core components. If you need to create a new core component go back to step 1. With all your fancy tooling, it can be as fast as 1 minute to build a new page.

https://twitter.com/karrisaarinen/status/849733176150773761

5) When core components change, go back to the "source of truth", the react-primitives code and modify that. Re-run react-sketchapp. Now all sketch files that depend on that core component will be automatically updated because of updated sketch symbols.

This looks great. And Sketch is incredible. I wish there was something like it available on Linux, or I could run it on Linux somehow. Seeing how important a tool it's becoming to web design makes me uneasy as it's shutting out my ability to do anything design related :/

I keep an old Mac around for exactly this reason. However since version 43 they've switched to a new file format offering "more powerful integrations for third-party developers".

The new format is a ZIP containing a bunch of JSON files per page, so maybe someone will come up with a cross-platform viewer or similar.

Edit: I found this which works with basic Sketch files: https://animaapp.github.io/sketch-web-viewer/

Oh that's excellent to hear. Openly usable formats are great.

Most of the slickness of Sketch is in its UI though, it'll be tough to replicate. Do you know of any project attempting to do so?

check out Figma!

Yep I've used Figma before. It's not really on par with Sketch, but it's certainly high quality.

Unfortunately, there's still a bunch of internal Sketch APIs we have to call, though radically, radically fewer than in the version of react-sketchapp pre-Sketch 43.

see also https://github.com/xaviervia/sketch2json for some interesting stuff :)

Would it be possible to use this on the server to create complicated PDF files for download (react -> sketch -> pdf), without using something like this current process (react dom -> html, css -> phantomjs -> pdf)?

Yeah sure - the caveat is that you have to run it on OSX rather than Linux. We have a bunch of Mac Pros & Mac Minis laying around the office doing CI funtimes.

I also hear whisperings of a react-pdf renderer but I haven't seen it

+1 for this idea!

This will come really handy, thank you. I'm trying to build a better infrastructure at work; do you have anything written up about how you work at Airbnb? Your "bring design & engineering closer together" mission sounds like what I'm trying to accomplish, would like to read/chat more about it.

We haven't written nearly as much as we'd like, but here are some you might like:

Design Ops (the org that contains my team - Design Tools) - http://airbnb.design/designops-airbnb/

The Way We Build (head of design @alexoid talking about our process) - http://airbnb.design/the-way-we-build/

Building a Visual Language (on our design system) http://airbnb.design/building-a-visual-language/

That's really helpful, thank you!

This is great, thanks Jon. I've been struggling to find good workflows for integrating design and engineering (especially when there is a disparity in maturity of the processes for each party).

I think there is definitely a gap in the "literature" for this topic and will be eager to follow any other progress you can share.

Would recommend joining the Design Systems Slack [1] and attending the Clarity conference [2] to meet like-minded folks!

[1] https://twitter.com/jina/status/713173129263067136 [2] https://www.clarityconf.com/

I asked something similar when AirBnb announced Lottie, and the team (Jon Gold included) replied with great insights. I hope you find this helpful: https://news.ycombinator.com/item?id=13547053

Nice, thank you a lot!

What is a "Sketch document"? I didn't see a link or explanation in that page.

Sketch is vector based design tool for designing UI and Sketch document is the format that it uses to save those designs. https://www.sketchapp.com/

Thanks!

The website slows down my chrome browser to the point where it lags and I have to backout.

Noticed the heavy CPU usage as well. The laptop still performed admirably but estimated remaining battery time fell below 2H on a full charge so I smelled something amiss. Turned out the videos on this page continue playing even when the tab is open in the background (not active tab, nor active window). Seems like a complete waste of cycles. (Opera Beta)

Sorry - wasn't sure of a good solution for this without rewriting our blog too.

Some things I tried: - not autoplaying the videos (but they're super short, so it would be annoying to click play) - playing them when they're in focus & pausing afterwards (would have to mess with our WordPress installation instead of launching this thing) - using GIFs (they were HUGE - I couldn't get them below like 2mb each) - YouTube embeds etc (ugh)

I thought this was the best compromise but yeah. Sorry :(

The classic way for reusing style and layout in web development is to have the style in CSS-files. CSS-files have a URL, so you can include CSS across web pages and take advantage of CDN's and browser caching. CSS have it's problems, but CSS is far superior to in-lining the style al la components. It's good practice to use the native browser components, the component might work very different on a smart-watch, vs a big screen PC, native HTML component will work on both devices! And native HTML components also work with JavaScript turned off! and for visually impaired people using different kinds of screen readers.

Jon was gracious enough to visit us at CollectiveHealth to describe their DLS processes as well as give us a glimpse of what was coming.

Design Systems and related tooling makes total sense at certain scale and I can definitely see both designer and developer efficiency gains from consistent building blocks that Design Systems provide. Jon I'm curious if this would still make sense if AirBnB weren't so invested in React and React Native.

Hey Vlad!

You could still use it for styleguides for type & color etc, if you keep those definitions in JSON.

if not, probably not :(

We have just recently started using React for new products that our team develops, doing the design in Sketch. This was already a huge improvement in efficiency compared to doing design in Photoshop and building products with Angular. I'm super excited to try this library on our next project and see how it can streamline the design and development cycle.

It's great to see a company like airbnb developing and open sourcing so much cool stuff. Are you guys hiring developers?

:) always! https://www.airbnb.com/careers/departments/engineering

A boilerplate project to create react-sketchapps

https://github.com/brijeshb42/react-sketchapp-boilerplate

Sketch.app name similarity with SketchUp can be a source of some confusion.

We're deep into the woods of name confusion now, all the easy names that relate to what an app actually does are taken.

Very cool.

It would be even cooler if it could render React components written for the web without modification, maybe in a transparent webview. I'm guessing Sketch would need to add support for that.

If we can figure a way to translate React DOM to React Native-style components then this will be doable.

You could write a codemod that turned <div> into <View>, <h1-6> into <Text> etc, but there's complexity in standardizing layout systems & CSS properties too. React Native-style components provide the best chance of us using React as a truly universal platform.

see https://github.com/airbnb/react-sketchapp/issues/37 & https://github.com/airbnb/react-sketchapp/issues/29#issuecom... for some more context

If you have any ideas on solving I'd love to see them in GitHub so I don't lose track of them :)

I'd really like to try to integrate some of this design philosophy (and what your team lays out in that DLS blog post, too) in my team's design flow. Thanks for this!

It's not really clear WHAT this is - why would I use it, what would I get if I used it?

I don't use anything from Airbnb (and no, I'm not a hotel or against the "sharing economy", much to the contrary).

Ok. Why not?

Reply on news.ycombinator.com