If you’ve done any sort of front-end engineering work over the past few years you’ve more than likely been inundated by the sheer volume of new technologies at your disposal. From Backbone.js to React, the rate at which new front-end technologies come out is rapid enough to make anyones head spin.
Staying abreast of the latest front-end technologies is hard, but determining which are suitable for your team and product is even harder. Here at Olark our front-end technology stack has evolved quite a bit over the past few years. From our early days of using vanilla JavaScript, to wrestling with large scale Backbone.js apps, to where we’ve landed today with React and Flux, our front-end stack has continuously evolved.
This blog post highlights how we’ve evolved over the past few years through trying new technologies slowly, field testing them on internal applications, and buying into low opinionated technologies. Additionally, we’ll cover how we disseminate new front-end technologies to our team.
In the beginning, there was JavaScript
I wasn’t around during the very beginning of Olark, but our initial front-end technology stack consisted of vanilla JavaScript files stitched together with a Python script and Rails for our dashboard.
As Olark grew so did our applications. As front-end tooling started to progress we adopted npm. When we started building out larger front-end applications we quickly realized we really needed a common framework.
One of the most popular frameworks at the time was Backbone.js. We primarily chose Backbone.js because it didn’t seem quite as heavy handed as a lot of the other frameworks and libraries that were also gaining popularity, such as Angularjs and Ember.
We found that Backbone.js provided just enough opinion and structure to our applications. If we didn’t like how Backbone.js handled data we could replace the models or collections and if we wanted a different view layer we could easily replace it. So, we happily boarded the Backbone.js train and took to writing numerous small applications throughout Olark in Backbone.js.
Coffeescript - Fresh Pots!
Coffeescript started to become popular around the same time we adopted Backbone.js and a few of our engineers wanted to give it a try.
At the time we were using browserify for module loading so we were able to easily add in Coffeescript asset compilation so that we could run both JavaScript and Coffeescript. Browserify gave us the opportunity to try out Coffeescript without fully investing in it in case it didn’t prove as fruitful as we hoped.
After a few weeks we quickly fell in love with how productive Coffeescript was making us, so we adopted it for all applications going forward.
Although we were feeling more productive with Coffeescript, we slowly started to see issues crop up as one of our Backbone.js applications started to scale beyond a meager handful of models, views, and collections.
We began to see obscure bugs where some views in our application would update with correct data while others wouldn’t. We slowly realized that we were in two-way data flow hell. We had multiple views listening and changing the same models and collections, thus making debugging and tracing data flow extremely challenging. We’d solve one bug and see a similar one crop up later on.
Around this same time we started to hear about a library called React and an architecture called Flux that the front-end community was raving about.
React and Flux
React is a JavaScript library created by Facebook for building user interfaces.
What’s amazing about React is that data flows in one direction through your views, from parent view down to sub views. The views also only render the parts of your view that have changed. So you no longer have to completely re-render the DOM on every change or have piecemeal render helpers littering your code base listening to an attribute change, which makes debugging much easier as you have a single state object to describe your application.
Flux is an application architecture for building user interfaces, not necessarily a specific framework or library. Flux is like the brother of React and provides one-way data flow through your application, which also makes debugging much easier and faster.
As we watched Facebook’s React and Flux introduction talk one of their slides described a network of models and views where data flowed bidirectionally, from views to models and from models to views. It seemed that they had apparently solved one of the biggest issues that we ourselves were experiencing. We decided that we had to try out React. However, before jumping on the React bandwagon, we learned from Backbone.js that we should put a framework through its paces before buying into it entirely. What better test ground then an internal application that isn’t customer facing?
At Olark we have quite a few internal tools. One such application is pancake, a small tool that aggregates collaboration data from Trello and a few other sources so that you can get a general overview of who’s working on what here at Olark. Internal tools are a great way to field test frameworks and new technologies because they have no direct customer facing impact. We implemented pancake in React and quickly fell in love with it. We decided to implement the next front-end project, the new Chat Ratings dashboard, in React.
Remember that one of the reasons we chose Backbone.js is because of its non-opinionated nature? Well, that proved to be a great decision. To help ease the learning curve and migration to an entirely new front-end technology we decided to keep Backbone.js around for data management and only replaced the view layer in Backbone.js with React.
Simply replacing the view layer in Backbone.js lowered the learning curve for engineers and designers and afforded us the opportunity to switch back to Backbone.js’s view layer should React have unforeseen challenges. React proved to be a great success in the Chat Ratings project.
When the Chat Ratings dashboard was released into the wild, bugs were quickly and efficiently squashed because there was so little two-way data flow and because there was a single state object which described our entire application. As you might imagine when learning a new technology there is always a learning curve and a few gotchas that crop up. During the Chat Ratings project we kept a list of tips and all gotchas that we encountered. At the end of the project I gave a presentation and code walk through to the engineering team, to give an overview of React and to disseminate all of the tips and gotchas the Chat Ratings team had encountered during building.
Although the Chat Ratings dashboard was a huge success to our engineering team, we still found that we retained some two-way data flow since our parent view controller was still communicating directly with Backbone.js models and collections. We decided we wanted to once and for all excise Backbone.js from all future front-end applications.
Flux (Capacitor)
Around this time we began experimenting with Facebook’s Flux in our internal tool, pancake. Remember, internal tools are a great test bed for new technologies. Flux proved successful in pancake as well by making development time even faster by providing a clear separation of concerns and by making bugs easier to find since we had one-way data flow.
When it came time to code the new Shortcuts dashboard application we decided to go all in with Flux and React. We followed the same pattern of keeping notes about things that tripped us up or things that weren’t intuitive as we developed the application.
When the project was released it was also a huge success. We had one-way data flow throughout the entire application, which made bugs that were discovered extremely easy to find and fix. Once again we followed the project up with a presentation of Flux, both the technology and tips and gotchas we learned while developing, and a code walk through of the project to the engineering team.
Making Tough Choices
Deciding to use a new technology in your stack is a difficult decision. With the rate at which new front-end technologies come out you could probably switch your front-end stack every few weeks if you wanted to. However, you have to strike a balance between being forward thinking and pragmatic.
When you do decide to try out a new technology try to first experiment with it on a low impact area, such as an internal tool. If your internal tool experiment proves successful and you want to take it to production, be sure to set yourself up for success should you run into issues; e.g. we originally chose Backbone.js due to its non-opinionated nature which allowed us to later on easily swap in React for its view layer.
As you try out new technologies keep a notebook of gotchas and tips that you encounter to save your fellow engineers from the same mistakes. Lastly, look to switch to new technologies when it solves a specific problem you’re facing. Is development slow? Maybe it’s time to look at switching to something new.
Our front-end stack has continually evolved to solve problems we’ve faced. We needed structure in our applications so we turned to Backbone.js. We faced two-way data data flow issues so we adopted React and Flux. Until we run into issues with React and Flux we’ll likely continue to build out and migrate old projects to them.
Oh, sorry, I have to run, someone just pinged me about a new technology that’s going to solve this issue I’ve been seeing in React and Flux lately...just kidding :)
