React.js Q&A

An interview with a development team who have recently implemented React.js into their project.
By James Pain Posted 10 June 2016

React.js Q&A

Below is a interview with the Front End developers of the VePanel team talking about the story of how and why they implemented React.js into their project. The transcript is edited for readability. Video of the full raw interview can be found here.


Hi guys. Let's start by introducing yourself.

Bartosz: I'm Bartosz Staryga. I work as a Front End Developer for Ve Interactive. I work for the VePanel team. We're responsible for changing the way our Apps are presented on our client's website. We're currently changing from the Overlay approach of our previous VeApps, into the more Widget like approach of Panel.

Florian: I'm Florian Barbare. I work as a Front End Developer, on the same team as Bartosz.

Ramesh: I'm Ramesh Anandakrishnan. I work as a Front End Developer on the VePanel project, same as Florian and Bartosz. I'm pretty new to the team, being here for three months now.

What is VePanel?

Florian: VePanel is a container for Apps, known as Components. It's a wrapper that allows us to build Components to be placed on a Client's website. It uses the same Apps we were using before on our Overlay system, but presented in a whole new exciting way in Panel.

You have recently started using React.js. What is React?

Bartosz: React is a framework that helps render and manipulate the HTML of our website application. Before, we were using vanilla Javascript, meaning we were building each HTML element in a very manual, complicated way. There was no community behind it. We didn't have tutorials on how to follow up the code structure. When Ramesh joined, he showed us React and that it can do all the complicated work for us, instead of having to reinventing the wheel. We found that it was a much better option, so we started using it. With React, you can just Google 'How to React', read a couple tutorials and you're already set up. We no long need to walk people through our code.

Why did you choose React?

You can just Google 'How to React', read a couple tutorials and you're already set up. -Bartosz

Bartosz: When Ramesh joined the team, we had to explain to him how all the stuff worked. We found it was a lot of explaining, and realised the system has gotten overly complex over the time of developing it.

Ramesh: We sat down and tried to simplify the solution. We looked into multiple libraries and frameworks that can help us simplify what we were doing, React being one of the options. There was a huge influence factor that Facebook was using React. We looked at Angular as well, but Angular version 1 was pretty much in the final stages of being a current technology, and Angular 2 was still in beta mode, so we didn't consider Angular seriously. We wanted to see how easy it was to use React on our project. Over a matter of days, we were able to get the our framework set up in React.

Bartosz: Having introduced React into the project, this process became much easier. Since Ramesh knows how React works, he could easily read the code by himself and follow the structure. Introducing new components and new parts became much easier.

When, during building the project, did you decide to begin using React?

Ramesh: I think it was when we had a finished project in Angular Javascript. React was meant to replace the complicated logic we had in Angular, with something that is simpler to understand and digest.

How easy was it to adopt React?

In a matter of days, we had the first pull request. -Ramesh

Ramesh: We work with a Spanish team called ToroRosso. Initially, before we introduced the React Panel to them, they had trainings session with Florian to explain how the whole repo works. They came back with a lot of questions. After we implemented things with React, we had another meeting with them, spending a couple hours explaining how the new Panel with React worked, and they completely understood. In a matter of days, we had the first pull request from them. That's a drastic change from them spending a whole week trying to understand how the old repo worked, to spending a couple hours understanding how the new Panel on React worked. It was a lot easier for everybody to grasp. One of the things we lacked in the previous repo was documentation. With React, everything is very well documented. If you need help, you can just post a question on StackOverflow, and you'll get a response for it.

Since implementing React, do you think it was the right decision?

So far, it was the best decision. -Florian

Florian: So far, it was the best decision. We've managed to reduce the complexity of our system. At the beginning, we were generating static HTML server side which was served as-is. We're now able to get rid of this server, making the whole system much easier to understand and much easier to deploy, which is pretty useful. It allows us to do much faster deployments from what was a few projects, to now only one project.

Now that the HTML is generated on the client side, what kind of performance implications does it have for the user?

They most likely already have the files cached from visiting another of our client's website. -Bartosz

Bartosz: It didn't, that's the funny thing. We can even say it's a little bit faster. Before, when HTML and CSS for every app was generated server side, we had thousands of unique files to be served, per app per client. Now with React building the Panel HTML on the client side, we serve one exactly the same HTML, CSS and Javascript file, which is used by React. We can even assume that since we have thousands of clients, when the user enters our client's website, they most likely already have the files cached from visiting another of our client's website. This makes it feel faster, in terms of how the users perceive it.

Ramesh: We were concerned with the React file size, but later we understood that React is used by Facebook, so React will have likely been cached anyway. The only thing that's required is a unique JSON file.

I remember you guys did a presentation on this in the VeLounge. When you mentioned it was the same file that Facebook was using, and we were using the same host for React, the question he brought up was 'What if the Facebook hosted React goes down?'

One deployment, and all the customers are instantly updated. We can do that in minutes. -Florian

Florian: We have all customers working on the same version of the HTML that references the URL to the React file. What we do is just change the URL on the HTML in the repo, do one deployment, and all the customers are instantly updated on the new React.js URL. We can do that in minutes. This is the benefit of having our deployment much simpler now.

Bartosz: And let's face it, if the Facebook servers go down, the whole internet will be down.

You guys have worked on other VeApps before, such as Assist or VePrompt. This is your first attempt at a versionless system.

Florian: We removed versioning when we built Panel. We were tired of having to update the version of the client side our clients were using individually. We just wanted to get rid of it, so we moved Panel to a completely different repo from the versioned client side and Apps, and we started doing it versionless. We were a bit worried in the beginning that we would have some problems and would have to go back to versioning, but right now, we have good confidence in our project. We've put tools in place, we have all the unit tests, we have integration tests, we have acceptance tests, we have as much as possible to make sure when we deploy something, we won't break anything.

Bartosz: At the end of the day, it's easier for us to roll back a version if something actually breaks stuff on a versionless system, than to update a few thousand clients to a different version.

To recap, when you deploy a new version of Panel, suddenly, all clients at once get the new changes you deployed instantly.

Florian: It depends how we approach it. Most of the time we work with feature toggles, so we can test our features on the live environment on a few clients. Once we're sure it's going to work for all clients, we roll it out for everybody.

Finally, would you recommend React? Obviously your answer is yes.

Florian: Yes! That is our answer!

Ramesh: We would recommend React, but I think one of the important things we actually did was to sit down, Spike it out, and to get the things working first before we present it to the Higher Ups. Having a working example paid off. I definitely recommend people try out React for their projects to see how it would help them out or how it will simplify their process.

Bartosz: We strongly suggest for people to be innovative, look for new technologies, and to try them out in the projects they're working on. I was sceptical going with React, and now I think it was the best choice we made.

James Pain
James Pain
Software Engineer