Building a Better Web
June 19–20, 2017: Training
June 20–22, 2017: Tutorials & Conference
San Jose, CA

Atomic design as a migration strategy

3:35pm–4:15pm Wednesday, June 21, 2017
Secondary topics:  JavaScript frameworks and libraries (Angular, React, Ember, Vue, etc.), Maintaining sites and applications, UI frameworks and libraries
Average rating: ***..
(3.50, 2 ratings)

Who is this presentation for?

  • Frontend developers

Prerequisite knowledge

  • Basic knowledge of JavaScript and HTML

What you'll learn

  • Explore the atomic design process and see how it was implemented at one company

Description

Atomic design is well suited for migrating web applications. Because you build complexity out of simple components, you can start small and slowly carve out your application. Harrison Harnisch shares how Buffer is migrating its codebase with atomic design.

Over the past six years at Buffer, 60 contributors have generated over 50,000 commits. Buffer had been seeing diminishing returns in developer productivity and performance from its codebase built on PHP and Backbone, so it decided to update its stack. Migrating a large codebase can be very challenging. Doing a full rewrite in a separate repository would require splitting resources in a way that would delay features and fixes in the old application and slow down development on the new application. It’s also very likely that regressions would occur.

There is something to be said about having a clean slate to work with. It means you don’t have to compromise on architecture and design. This is where atomic design principles shine. With atomic design, you can slowly migrate to a greenfield application.

Atomic design defines the most basic building block as an atom. Atoms can be joined together to build more complex components like forms or search bars. The process of migration starts with a simple atom (like a button) that can replace a small part of your old application and simultaneously be added to the new application. You then build a few more atoms (like an input and a label) and stitch them together to make a molecule (perhaps a form). The molecule is added to the old application, replacing just a little more functionality while also being added at the same time to the greenfield application. This process is repeated until there is just the shell of the old application. When the shell is the only thing left, it’s possible to swap out the old application for the new one.

Migrating with atomic design enables the development team to move at a natural pace while continuously delivering value. The process spreads out regressions and bugs over time, reducing the risk of fire drills and pager duty alerts at launch, meaning that development teams can build on momentum rather than fear of missing deadlines.

Photo of Harrison Harnisch

Harrison Harnisch

Buffer

Harrison Harnisch is a senior software engineer at Buffer, where he is implementing the transition to microservices with Kubernetes and Docker. In a former life, he was the touring drummer for the band The Sweethearts of the Radio (not the famous one).