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?
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!
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.
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.
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.
The next article in this series is: How we manage state.