My start with React

Atlassian’s first production React

In October of 2014, I was made the front end lead for a new team at Atlassian simply called “purchasing”. Our mandate was to develop in application interfaces that customers would use to administer their payment options. The user story reads something like “As an administrator I can view my bill, add and remove products and update my credit card details from inside my OnDemand account”. Things one would expect to exist given that Atlassian had, at this point, been wildly successful selling software for nearly twelve years.

Our behind the firewall legacy had left us with odd user journeys whereby in order to manage the credit card used for payment, downgrade or yes, even pay Atlassian more money, a user had to login to a separate system. This was deemed “awful” and scheduled to be fixed.

The small team shipped Atlassian’s first user interfaces to use React three months later in January. Since that initial team’s success, React has gone on to be one of most quickly adopted technologies at a company with historically lagging uptake of trendy new front end things.

While I made the initial call to use React and some training as new developers joined the team, I can’t claim credit for it’s wider adoption at Atlassian. A combination of individuals outside the company such as Pete Hunt, attacking the conference circuit with apostle like effectiveness, and Twitter/Hacker News hype did most of the work.


React at the time was what exactly what it says on the tin, an efficient view layer. React allows creation of custom components “Components”. It doesn’t aim to do two way data binding, this is a feature not a bug.

My team was not initially looking for an efficient view layer. The draw for us at the time was that a customer’s details for these pages was essentially a tree: what products they owned, numbers of users for said products, and upgrade/downgrade options for the product. A customer only had only one to five products making it a narrow but sometimes deep tree. This lent itself naturally to React’s component style and since the user interactions consisted almost exclusively of button clicking we wouldn’t miss two way data binding.


What wasn’t mentioned on the tin at the time, but is now, is that this view layer works best when one does several other common layers differently. When we started hacking, the Flux Architecture document wasn’t published yet, much less Flux itself. Relay wasn’t even a whisper so far as I remember.

An interesting thing about Flux at this point is that one could look at the code and understand that it felt like it wanted to be done differently. While we came close some of the time: data and components as a tree. We got it wrong in others: eventing.

Relay was not like Flux in my experience. Not only did we not have it, we didn’t know we wanted something different. We made ajax calls and passed data around as a large object, this didn’t work well. Developers were often confused about what data an object would contain at any given phase of the application flow. I always felt like types would have saved us. While I moved on to other projects, the team that remained later tried TypeScript, they tell me it’s a really killer combination.

Modern React at Atlassian

React has become widely adopted and is already shipped in multiple high priority projects. It’s used in or is planned to be used in all major products and there are occasional musing about it becoming a kind of de facto standard by being folded into the internal widget library.

There are challenges for adoption of course. Companies are rarely of one mind. There were earlier strong bets on Web Components. Skate is an impressive library and I expect React to find itself swimming against the current as Web Components seem poised to take center stage over the next few years. That being said, this isn’t React’s first rodeo.