How and why we chose React

September 18, 2020

Post

This article is part of a blog series in which we look at back at five years of React usage at Instana.

Most of the early Instana employees moved to Instana from a German software consultancy called codecentric. These first employees experimented, used and trained customers in various UI libraries and frameworks while working for this consultancy. This background allowed us to have a broad understanding of the web development space and Zeitgeist. When it came to actual usage in projects and at customer sites, it was widespread to use

  • Vaadin – shall I hide the web from you?
  • AngularJS – digest cycles, anybody? 
  • Classic server-side rendered apps – a big jQuery mess?

January 2015 was still very early for React with minimal adoption for production systems. After all, the library had only been open source for about 1.5 years and it hadn’t even reached a 1.x.x version. Whether you agree with the latter or not, it was deemed a characteristic of maturity, especially around this time where the software community was starting to mock the JavaScript ecosystem for its churn.

A critical event for us was Pete Hunt’s well known JSConf talk in the second half of 2013. The talk resonated with us because it captured best practices we identified ourselves in past projects. For complicated UIs, it is typically a whole lot easier to avoid manual mutation of one version of a UI to another, e.g., addition/removal of buttons on input changes. Instead, it is simpler to mutate state and express UI rendering logic as a function over state. We used this pattern within Vaadin projects before even though this was wholly unoptimized and therefore expensive. We were thrilled to see that the team behind React had similar learnings and a lot of additional smart ideas which they formalized, evolved and shared with everyone!

Product Vision

Instana was like many other startups at founding time: A tiny group of motivated people sprouting with ideas, enthusiasm, and little desire for formal documentation outlining anything resembling functional or non-functional requirements. What we did however have were orally communicated ideas, fruitful discussions and inspiring designs. Let us now look at some very early stage designs that showcased the vision.

A 3D representation of a software stack.

One of the earliest ideas for our 3D infrastructure map.

The image above shows one of the earliest designs of our 3D infrastructure map. The 3D infrastructure map shows monitored hosts, containers, processes, databases and more to give users an overview across their physical infrastructure. Our designers went wild with this idea!

  • Tron-like yellow lines firing whenever processes communicate with each other? Hell yeah!
  • Shall we visualize tables for databases in 3D? Let’s try it!
  • Wave effects and under box lighting? That is going to look nice!

Iteration and refinement resulted in designs that were getting closer and closer to what Instana is today. Not all of the fancy ideas turned out to be useful. We dropped, refined and revised many of these over the years. For example, the Tron-like effects were major distractions for a tool you use daily. 2015 PC/Macs (and their older counterparts in enterprises) also didn’t really like all these effects and movements.

The design above shows important aspects aside from the 3D map: Charts and huge metrics that are supposed to update every second with new data pushed into the UI. Live updates at 60 FPS! The following design idea also shows one of the prime examples for Flux architecture: Presenting the same state in multiple locations and keeping that state in sync.

3D server visualization with metrics on top and around it

Next iterations are showcasing some important aspects that drove Instana’s UI architecture.

Choosing React

We settled on React pretty quickly. It would be a lie to make this look like a fancy architectural decision process that was well thought out and contrasted libraries’/frameworks’ pros and cons. In all honesty, this was mostly a gut feeling. After all, we are a startup that isn’t even a month old!

However, we knew that a server-side rendered approach like ROCA-style was not going to work for us. All ideas and designs pointed to

  • very high levels of interactivity,
  • frequent UI state updates pushed into the web browser,
  • components that cannot be rendered on the server-side, e.g., 3D content, and
  • it would also have been incredibly challenging to ensure synchronized state between server-side and client-side rendered content.

For us, it was also clear that frameworks such as Vaadin and AngularJS were too opinionated and rigid. React, in contrast, has a simpler conceptual model. This model meant that it is a lot easier to reason about its behavior, improve performance and integrate non-React libraries. An easy integration path for libraries was critical, as we knew that we had uncommon needs. The thought of having to write a lot of AngularJS directives to cover those needs was scary. React made this simple.

React was still establishing its market dominance in 2015. This caused the ecosystem to be comparatively small (albeit growing fast). Due to React’s flexibility, however, this wasn’t a problem as we could easily integrate any JavaScript library ourselves.

The next article in this series is: How we manage state.

Play with Instana’s APM Observability Sandbox

Developer, Engineering
This article is part of a blog series in which we look at back at five years of React usage at Instana. State management is one of the essential aspects of React...
|
Developer, Engineering
This article marks the start of an article series in which we would like to look back at one of our earliest technology choices: The selection of React. React is being used...
|
Announcement, Product
The majority of organizations will ship production JavaScript code both minified and bundled into a single source file in order to speed up page load time. When reading JavaScript stack traces in...
|

Start your FREE TRIAL today!

As the leading provider of Automatic Application Performance Monitoring (APM) solutions for microservices, Instana has developed the automatic monitoring and AI-based analysis DevOps needs to manage the performance of modern applications. Instana is the only APM solution that automatically discovers, maps and visualizes microservice applications without continuous additional engineering. Customers using Instana achieve operational excellence and deliver better software faster. Visit https://www.instana.com to learn more.