Bravado’s Framework Evolution (Part I)

By Anton Pleshivtsev, Nancy Zhu

Rails-Only Framework

In Bravado’s first year of operation, three developers built our web application entirely with Ruby on Rails. Due to the lean team and our proficiency in Rails, it was straightforward and efficient to build Bravado’s products using this single framework.

However, we soon realized it wasn’t a scalable solution due to two main problems:

1. Configuration complexity: As we expanded our product roadmap, it became increasingly difficult and time-consuming to configure and support our front-end development using a back-end-oriented stack. For example, we needed to configure webpacker, a Rails wrapper around webpack, a front-end build system. Configuring webpack is an already difficult task, and configuring webpacker introduced additional complexity — we would have to use YAML configuration of webpacker to configure JavaScript-based webpack configurations living in a different folder and then split them into parts and environments.
2. Hiring: As we needed to hire more front-end developers to support Bravado’s growth, the requirement for front-end candidates to master Rails, a back-end-oriented framework, drastically shrank the size of our candidate pool.

To develop and hire more effectively, we decided to evolve our framework. Specifically, we started exploring standalone front-end stacks (including framework, configuration, and build process) to use along with Rails. Within two years, the Bravado developer team completely transferred our web application from a Rails-only framework to a Rails + Nuxt monorepo, without investing a significant amount of engineering resources or disrupting Bravado’s product development.

React.js

We first tried out React, one of the most popular libraries for front-end development. The Facebook-developed library is easy to use, widely adopted, and conducive to faster development and rich user interfaces, among other reasons.

But it wasn’t a great fit for Bravado. Because React is a library, our developers often needed to build components from scratch or dig for quality open-source solutions from big companies, which was both time-consuming and unproductive. For example, when we were implementing our autocomplete and routing libraries, all the suggestions by the React ecosystem were either incomplete, partially broken, or incompatible with the modern versions of other tools.

In search of a more established alternative, we started exploring Vue.js.

Vue.js

Vue.js is an open-source front-end JavaScript framework developed by Evan You, a Google alumnus, based on the Google-developed AngularJS.

We built a customer testimonials feature using Vue.js and React.js to compare them. A user would request a testimonial from a previous customer; when the customer finished writing the endorsement, it would appear on the user’s public profile page.

At the end of the development processes, Vue.js became the clear winner. The feature took 20% less time to build in Vue.js than in React. We also experienced a less confusing, more enjoyable, and most importantly, more streamlined process using Vue.js. You can see the finished testimonials portfolio product built using Vue here.

Here are the main reasons why we picked Vue.js over React.js:

1. Ecosystem: Instead of rummaging for solutions for every feature to build in the open-source community like we did working with React, we got access to a comprehensive, supportive ecosystem maintained by the Vue.js core team. The Vue.js ecosystem consists of a developer forum, essential tooling, as well as core libraries at our disposal, which are powerful, easily-accessible resources we value.
2. Template engine: The template syntax used by Vue.js is more clear and declarative. The most popular syntax approach used with React is JSX (JavaScript Syntax Extension). As you can see below, JSX mixes code with markup, which makes it relatively difficult to understand and change. Vue.js, on the other hand, uses an HTML-based template syntax that allows us to declaratively bind the rendered DOM to the underlying data. Built from the AngularJS template, the Vue.js template contains clear conditions and can be operated by anyone with HTML skills.

3. Single File Components: The Vue Single File Components (SFC) format streamlined our file organization and delivery process. Using the SFC file format, we were able to combine our template, logic, and style of a Vue component in a single file instead of separate files (see below). This enabled us to send files in a consolidated rather than piecemeal format; it also eliminated the need for our team to discuss how to organize JS/CSS/HTML files in folders (i.e., separate folders for styles and code vs. folders for components as shown in the screenshots below).

4. Styling: We also benefited from the Vue SFC style features. In our SFC example, you can see the <style> tag has the scoped attribute. This applies the CSS to elements of only the current component. Scoping the style enabled us to isolate the styling for different components, further streamlining the development process.

Implementation & Impact

Implementation

Once we made the decision to switch from Rails to Vue.js, we still had to figure out how we were going to rewrite our entire frontend in a new framework. As a startup, we couldn’t afford to spend months just rewriting the codebase and not shipping any features. Instead, we were nimble enough to build every new product and design update using Vue.js, and within less than two years, we’d replaced the entire Rails frontend.

Impact

The adoption of Vue.js has made a tremendous impact on our development and hiring process. With the Vue SFC and other features, we have eliminated the need to have internal debates about folder structure, file structure, etc. By removing the requirement of Rails experience, we have scaled our front-end developer hiring efforts and doubled our front-end team in 2020.

Introduction of NUXT

In the quest for the best framework solution, we did not stop our framework evolution there. Despite the strengths of Vue.js, many challenges remained, including:

• Configuring the build process for tools such as webpack. We only accomplished about 30% of the front-end code transfer with Vue.js.
• Moving a copious amount of code from Rails to the new framework. We lacked the resources to accomplish that within a reasonable amount of time.

In part II of our “Framework Evolution” series, we will discuss how we solved these problems with the introduction of NUXT and Nginx.

Bravado is hiring! To view and apply to open roles, visit our Careers page.