React Native has a lot of buzz around it. It is some serious and cool tech, yet can feel like a big departure from your native iOS codebase. At Artsy, we like it. It has been the right choice for us. We’ve documented our journey and reasoning quite extensively, but naturally, developers around the world are still wondering whether the trade-offs make sense to their team, and their situation.

Enter Artsy x React-Native.

Who better to partner with than Facebook? We’re bringing a day full of hands-on informative insight and practical play. With the focus on what building world class applications with RN can be like.

We’ll demo, through talks and workshops, how to add React Native bit by bit to an existing codebase, set your tooling up for success, and create solid animations.

We want Artsy x React-Native to be about getting you up to speed with the framework, so you can make your own decisions going forward.

As I write this, I have completed my first ever engineering on-call rotation at Artsy, so naturally I had to write a blog post about some of the things I learned.

Read on →

Over the past few months, we’ve been working on formalizing an on-call support process for our engineering team. This post details our current state and how we decided what system would work best for us.

Read on →

I have seen the future, and it looks a lot like GraphQL. Mark my words: in 5 years, newly minted full-stack app developers won’t be debating RESTfulness anymore, because REST API design will be obsolete. By the end of this post, I hope you’ll see what I see in the promise of GraphQL as a new approach to client-server interaction.

Read on →

When I began working at Artsy four years ago, remotely, I really didn’t like the weekly engineering standup. I’d sit in front of my computer and strain to hear a dozen people gathered around a laptop with Google Hangout. They’d discuss implementation details for projects I wasn’t familiar with, and then I’d do the same to them (our mobile team was still very separate from our web team). Twenty minutes would pass and I didn’t feel like my work experience at Artsy had been enriched in any way.

The first time I came to New York to visit the office – before moving here – I sat down with Dylan and Orta. Dylan ran the weekly standup, and Orta was also not a fan of the meeting. Dylan was clear: if the standup wasn’t working for the two of us, then it wasn’t working for anyone. So let’s fix it together.

Read on →

The third in our JavaScriptures series on the Artsy omakase. This workshop is a deep dive into Styled Components, where we take our React app from the first workshop and convert it to use Styled Components. We have Roop and Jon Allured covering all the details.

Read on →

The second in our JavaScriptures series on the Artsy omakase. This one is a deep dive in TypeScript with a minor-focus on working with React. We run through a series of excercises you can run through yourself here.

It’s ran by @alloy and Sarah Scott and covers compilation, errors, default types, interfaces, inference, generics and how they all come together in your tools.

Read on →

We’re a growing engineering team, and that tends to mean that people move towards being more specialized. This is great for an individual’s technical depth, but can weaken their breadth of knowledge on new technology. We want to encourage the growth of both within our engineering team. To address this our front-end engineers worked together to run a series of workshops for the whole engineering team.

We called this JavaScriptures, 6 workshop-style deep dives into the major parts of the Artsy JavaScript omakase. They are: React, TypeScript, Styled Components, Relay and Redux, Babel and Webpack. Today I’m posting the recording and slides from a deep dive into React hosted by Luc Succes and myself.

Read on →

Our mission at Artsy has been to make a world where everyone is moved by art every day, and at a high level, the way that our engineering team supports that mission is through building software. We have built systems and databases and user interfaces that represent different facets of the art world, and throughout our work, we have… made some mistakes.

That’s okay! Programmers make mistakes all the time. There is a large list of blog posts describing various programmer misconceptions, from subjects you might expect would be simple to model in computers, like units of measurement and time, to subjects that are based more in the human condition, like postal addresses and marriage.

In the interest of openness and sharing what we’ve learned, the Artsy Engineering team has come up with the following list of misconceptions programmers believe about art. Thank you to everyone at Artsy who contributed to this list.

Read on →

When we talk about our React Native setup in abstract, there are two kinds of “now draw The Tick” for iOS developers:

• How do I build this React Native as a CocoaPods setup?
• How do I get all the JavaScript tooling setup up?

We’re going to address the first part in this post. By the end of this post we’re going to get an Emission-like repo set up for an existing OSS Swift iOS app called GitHawk. The aim being to introduce no JavaScript tooling into GitHawk itself, and to only expose iOS-native UIViewControllers via a CocoaPod which is consumed by GitHawk.

To do this we’re going to use the CocoaPods’ pod lib create template, and React Native’s react-native init to make a self-contained React Native repo. It will export a JS file, and some native code which Podspec will reference. This keeps the tooling complexity for iOS and React Native separate. Read on to start digging in.

Read on →