Dev Discuss | Why we built our new UI in React, from the ground up

By Chase Doelling in Developer Posted Nov 6, 2017

Dev discussion with Aaron Fullerton, Cloud Elements' senior software engineer and occasional coffee enthusaist met with me, Chase Doelling, Cloud Elements' product marketer, to chat about React. Background: The new 2.0 release of the Cloud Elements platform was built from the ground up using React for the UI.

DevDiscuss-Aaron-1.png
 
Why did we build out the new UI in React versus other frameworks or libraries?

aaron.jpgOne of the main reasons we chose React is that it really empowers our developers. By puzzling together a bespoke solution based on a single library, rather than a full framework, we were able to be more creative, original, and innovative. I think those qualities are really important for an engineering team at a startup. Additionally, using React also helps us attract talented developers to join our team as the engineering teams themselves grow. A framework like Angular or Ember sets the boundaries on what you can do easily. It’s not that you can’t do the things you want or be creative, but rather that you have to fight to get what you want out of the framework. Whereas with React you start from an open world and push yourself to where you need to be. As a company we want to push ourselves.

Cloud Element’s original UI was a frankenstein mashup of Ext.js & Angular and was built into our monolithic java application. When we planned version 2.0 of our UI, we decided we didn’t want to be locked into our previous technologies or continue to have our UI and backend codebases in shared deploy cycle. For one, the old codebase was not well documented and was quite hard to maintain. Additionally, since the old codebase grew organically and very quickly, there was really only one developer that felt comfortable making style changes. Additionally, Ext.js itself just feels very “enterprisey”. Mainly in the sense that it is very configuration forward. You basically end up constructing giant Javascript objects describing what your UI should look like and Ext.js spits out this enterprisey interface. It really doesn’t feel much like programming but configuring. We were able to put that to the side and start from scratch.


RELATED BLOG: BREAKING our MONOLITH

What improvements have you seen since the change to React?

Our new UI is orders of magnitude better than our previous iteration. From the UX perspective, we’re now fetching data at the component level and allowing renders to occur while data is fetching, so the user is not stuck waiting while we gather the data necessary to display the page. In our old UI, you had to we gather all the data needed to display the page before beginning the first paint. Additionally, our old UI didn’t take advantage of newer browser features like fetch, pushstate, or local storage to name a few. These really helped us improve our UX by enabling URL based routing, better error handling, and on-device caching.

Computationally, we’ve also made huge performance gains. For one, React itself is very performant because it uses this idea of a virtual DOM. Traditionally, when a user is on a HTML page and triggers an action that causes changes to the DOM, the browser then has to recalculate the entire DOM, recalculate the CSS, and then repaint the entire page. Using a virtual DOM, which is really just an in-memory representation of the DOM, it essentially creates a diff of the page and patches only the elements needed to make a change. This results only in the minimum amount of re-rendering necessary. This alone leads to performance gains and as a bonus, also makes it easier to debug certain changes.

Coming back to styling, how has that impacted making updates from before?

In our new UI, we decided to use a CSS-in-JS approach, applied at the component level. As a developer, you don’t have to worry about the entire stylesheet and you can feel confident that you are just styling only what you are editing in the code. Before our rewrite, it was fairly scary to make style changes, because you didn’t know what the implications of a particular change might be - editing a button selector to make one page’s call-to-action a bit brighter might change something else in the application or result in an unexpected cascade. Now, what’s in the file is what is on the screen. It really empowers developers of large applications by allowing them to be more confident in the changes they are making.

What are some recommendations you have when looking to build a React app?

I would encourage developers to try not to take shortcuts early on. The React library itself is very easy and has a small footprint but the ecosystem around it can be very difficult to navigate. Because it’s not a framework, there aren’t a lot of best practices to pull from. What I have learned as a developer is to embrace the change and the gradient of abstraction that comes with it.

Many people new to the React ecosystem complain that there is a lot of boilerplate code, and that’s definitely true. For example, when you follow a Redux tutorial, you’ll probably create five or six different files to do one thing. You’ll write actions, action creators, reducers, components, and higher-order components. It’s frustrating and you don’t really understand why you’re doing any of it it first but I encourage others to embrace it and keep doing it. It sucks but eventually you start to see these abstractions that you can create. It’s a way to discover why others do things “this way” and how to refactor your code. It clicks. When you try to push it and skip steps along the way, things become difficult to understand and the mental model of React application becomes way too complicated.

Furthermore, I think people tend to get caught up in the “React Way” to do things. That becomes a trap in my experience. Fall back on your own programming experience. When looking at something like JSX and these somewhat foreign ideas take a moment to understand what is really going on. For instance, JSX is really just a functional composition of state - you can literally write it as a series of nested callbacks. Once you understand what’s going on, you can use your own experience and preferred patterns to fall back on. It doesn’t have to be “React-y”, there is nearly 70 years programming knowledge to utilize, even if it looks different.

Lastly, to the developers reading this that are just getting started with React, know that many pain points the community had early on have been addressed. I could harp on the idea of “embrace the suck” more, but to be honest a lot of the frustrating things that existed in the early days are not barriers anymore. There were some legitimates complaints about needing to learn how to bundle code using webpack and then transpiling your code through Babel, etc. But Facebook and the React community have done a great job of creating simple tools to get started and get past a lot of those things. Developers don’t even need to be concerned with the licensing issues React used to have. The barrier to entry is so low now compared to the early days. Just go build something cool (emoji).

How do you stay on top of the React ecosystem?

The best way to stay on top of the React ecosystem is to stay connected: follow people on twitter, watch repos on GitHub, and subscribe to newsletters from community influencers. Most of the really valuable content I have found comes from core contributors to React. People like Dan Abramov, Brian Vaughn, and Sebastian Markbåge all put out great content‏. Additionally, big players in the community like Ryan Florence, Tyler McGinnis, and Wes Bos all have great resources. When I read something about React, I try to put on my scientist hat and be skeptical of what I’m reading. I always value advice from those that are proven in the ecosystem much more than random developer blogs.

Do you think the current frontend trends will continue?

I hope they do. There are a lot of purists that want to maintain the status quo and talk about “separation of concerns” and whatnot. And there’s validity in that and the principles those individuals talk about. But I think the changes taking place in the frontend community are just new perspectives on these same principles. For instance, we are still separating our concerns, we’re just experimenting with idea that our concerns aren’t divided into the buckets, or files, around logic, presentation, and markup, rather we divide things by functionality and purpose into self contained components. You’ll notice that this new perspective on “containerization” is taking place in other areas of software engineering as well and I believe that we’ll continue to go down that path. If you think this is weird or goes against software engineering principles, I would encourage people to develop a mindset of curiosity and do some research. Find out why things gain so much traction and attempt to understand why there is value in those things. I mentioned earlier that there are 70 years of programming knowledge to fall back on when you need it, but remember there is only 70 years of programming knowledge to fall back on and there a lot of things we don’t know yet.

Subscribe to the Blog