Choosing a Front-End Framework

Jessica Sartin
Nov 25 · 5 min read

Why?

Last year, Panorama’s engineering team set out to choose a front-end framework. Before this endeavor, our applications were purely Ruby on Rails, using JavaScript only when necessary. We decided to move towards a front-end framework for a few reasons:

  • Robustness — We felt that our web applications, while usually consistent internally, felt fairly homegrown. We would prefer to build them in alignment with the broader javascript community’s practices.
  • Performance — While server-side can be fast, we were increasingly needing to create UI’s over larger and larger datasets which limited our use of server-side html rendering.
  • Reusability — We did achieve some reuse by our use of Rails view partials, but it still created a lot of boilerplate, especially for UI components and intricate JS logic.
  • Hiring — We had some evidence from engineering interviews that very skilled front-end engineers found it a very bad sign if we were still without a dominant front-end stack.

The Plan

At Panorama, we have a pretty flat hierarchy and make decisions via influence, not authority. This means we didn’t have a chief architect to choose a front-end tech stack, and instead brought a group of interested engineers together to evaluate our options and make a proposal to the engineering department. Once we had that handful of engineers to push this initiative forward, we developed a plan to select a framework. Knowing that this was a major decision and expensive to change later, we wanted to be thorough in our evaluation. A group of engineers met and decided on the following plan:

  • Compile a list of frameworks to research and develop rubrics to evaluate those frameworks against
  • Do some preliminary research on rubrics to narrow down which ones seem promising
  • Build prototypes of a complex front-end feature using each of the finalist frameworks
  • Finally, present our findings and get feedback from the rest of engineering to make that final decision

Frameworks and rubrics

To choose the frameworks to look into, we came up with ideas based on what seemed to be industry standards, and what engineers were generally interested in working on. We decided to investigate React, Vue.js, Stimulus, Polymer Project, and native web components.

In building our rubric, we first had a few themes of measurements, including philosophical balance, compatibility with our other technologies, features and functionality, and external resources available. In each theme we drilled down into a few specific items, like incremental adoptability, rails integration ability, perceived learning curve, and a strong community supporting the framework.

Initial investigation

We found some commonalities across all frameworks in our initial investigation. For example, every framework we evaluated allowed for incremental adoption and use outside of single-page applications. Though some had smaller learning curves than others, they all seemed compatible with other technology we use like Rails, and they all seemed to have enough information available that we could overcome the learning curve.

In some areas, the results were starkly different. Vue.js and React both have strong ecosystems behind them, like using Vuex and Redux for state, and Jest for unit tests. They are both fairly mature, so we wouldn’t expect major changes where an upgrade would feel like using a totally new framework. Finally, they both have large communities, including popular local meetups and even conferences. Thus, we decided to prototype both of those frameworks towards making our final decision.

Prototype

Now that we were down to two frameworks to prototype, we also had to decide what to actually prototype. In this case, we wanted to prototype something already built in our application, so that we could put the frameworks’ incremental adoptability to the test. Ideally, we’d all be working in an area of our applications that we were familiar with. This turned out to be pretty difficult as many of us were new engineers.

We settled on prototyping our user management tool. We realized that multiple squads had done work on the tool, so we had two engineers familiar with the tool. Each of us paired with another engineer and each pair picked one of the two frameworks.

Struggles and successes

We discovered that prototyping was a lot more complex than researching the tools. Research wasn’t too hard to fit between meetings. To prototype, we had to ensure our dev environments were set up (for some of us, in a different application than we usually worked in) and then we had to build the features while learning the new tools. It was also harder to shift away from writing code for normal squad work to writing code for a side project.

Over the next few weeks, we gradually shifted our tactics to make progress on the prototype. Each group realized it would be better to set aside time for pair programming, which had a few benefits:

  • The time was blocked off, making it easier to step away from normal squad work.
  • Only one person on each given day needed to have everything set up and working.
  • It was easier to work while one person drove the code, and another could research how the framework works.

While this helped, after a few weeks we were still disappointed at the progress we hadn’t made. An hour is not much time to get into the groove of coding, especially with an unfamiliar technology. We decided we needed larger blocks of time, so we scheduled some large blocks of time we could all use to make progress. These afternoons led to great progress on the prototypes, helping us decide as a group that both frameworks felt like feasible options. It was time to call the prototypes done.

Then what?

On realizing that either framework would meet our needs, we surveyed engineering to find their preferences and if there was anything more to consider in our decision. We asked engineers whether they preferred Vue.js or React, how strong that preference was, and if others had experiences to share. With 21 responses, the survey results didn’t lead to a clear favorite.

With those results, the working group went back to discuss the options. Knowing that either would meet our needs, we went back to our initial investigations and prototypes to deeply understand which framework would be better. We noted that Vue.js had a slightly easier learning curve. We also appreciated that the tech stack to go along with it was fairly standardized in the industry, so we didn’t expect more difficult decisions on how to unit test or bundle the code. Additionally, we anticipated another difficult task to begin rolling out a new framework. Since Vue.js had a slight edge in our survey, we were excited to propose the framework with more engineers passionately supporting it.

Since engineering decisions are made collectively, we had one last step to finalize Vue.js as our framework of choice — agreement from the rest of the engineering team. Thankfully, our research, prototypes, and final decision making were easily understood by engineers and the whole team agreed to move forwards with Vue.js.

Vue.js logo
Vue.js logo

Are you interested in seeing where our Vue.js journey has taken us, and being part of future technology decisions? We’re hiring!

Building Panorama Education

Jessica Sartin

Written by

Software engineer and leader. Somewhat cat obsessed. Lots of reading, occasional writing.

Building Panorama Education

Stories and musings from Panorama’s design/engineering/research teams

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade