Why VTS is Moving Off of AngularJS

Picking a front-end framework is like buying a new car: there are a lot of options, you probably have biases against particular manufacturers, and every car has its pros and cons. And each time you buy a new car, there’s also another one getting left behind. No matter how many memories you‘ve made, how many trips you’ve been on together, or how much time you’ve spent trying to increase its performance, there’s a time when your old ride just isn’t doing the trick anymore. And sometimes, just sometimes, Google will deprecate your old car and tell you they’re not going to fix it even if it breaks because they changed the latest model so much that it uses an entirely different syntax. Alright, enough beating around the bush, let’s cut to the chase.

Note: I’m going to refer to all methods of writing web applications as frameworks, though I am aware that some of these technologies represent only a portion of the associated framework and are technically just plain old libraries.

Last January Google announced that they will be deprecating support for AngularJS in favor of Angular (sometimes referred to as Angular 2+, Angular 4, etc. but from here on out I will be referring to it as Angular). This posed a very difficult question for us at VTS: What framework do we want to have our application built with in the coming years? Should we stick with AngularJS and hope it serves our needs for the foreseeable future? Or should we perform the laborious task of migrating to a new framework? While we have already made quite a substantial app with AngularJS, we deemed it necessary to migrate to a new framework given 1/ dwindling support of AngularJS libraries (and AngularJS itself), 2/ increasing difficulty in recruiting folks who are excited about AngularJS, and 3/ our current team isn’t happy with AngularJS, because it often feels like going through a lot of hoops to do simple things. BUT that’s not to say the road that lay ahead of us was easy; we still needed to actually pick which modern framework we wanted to go to. In order to do this, we wanted to examine all of the viable options and assess how difficult it would be to migrate over. We identified VueJS, Angular, React, and Ember as the contenders.

Evaluation Strategy & Criteria

Going in to this evaluation, we had a couple requirements that we knew we wanted to stick to as closely as possible. At the very least, we knew we wanted to 1/ be able to migrate our app incrementally in order to reduce risk, 2/ be on a supported tech stack, and 3/ be on a tech stack that our engineers are happy with and promotes fast and efficient product development. In order to judge each of the frameworks on a level playing field, we came up with the following actions to take for each:

• Talk to other companies who had already performed a similar migration¹
• Make a sample app with each proposed framework. It should contain an index view, a generic reusable table component, and a form that fetches some individual record asynchronously.
• Take a small section of our app and see what it would be like to convert it to the new framework. Start with a simple presentational component and then level up to its more complex container component.

While doing these investigations, we tried to stay consistent and keep in mind the following criteria as well:

We want our ideal new framework to…

• Interface easily with AngularJS
• Have thorough & concise documentation
• Have a strong community backing
• Easy to convert a component from AngularJS
• Easy to set up initially
• Ease of integration with our build system
• Test tooling
• Dev tooling

After evaluating each option through these vectors, we pulled together the list of options with some potential migration strategies, pros, cons, and some points that are a little bit of both. Here’s a summary of our findings:

VueJS

Ding ding ding! First up is VueJS. Vue was released in February 2014 by a former Google employee who used AngularJS in a number of projects and “extract[ed] the part that I really liked about AngularJS and buil[t] something really lightweight without all the extra concepts involved.” This was the one we knew least about going into the evaluation. I had a small amount of prior experience with Vue, but didn’t ever end up making a full blown product with it, more just tinkering around with it in CodeSandbox.

The Good:

There was a surprising amount I found I really enjoyed about Vue. It felt like a boiled down AngularJS (definitely a step in the right direction), and was very easy to pick up, especially coming from AngularJS. Here are a couple of the positives I enjoyed while evaluating Vue:

• Uses virtual DOM. This means it has great rendering performance and is on par with the rest of the modern front-end frameworks
• Great documentation. It was super easy to understand and was a pleasant read going through their initial guides
• Single file components ( .vue files) keep all the component logic in one place
• Styles can be scoped to a component. Can reduce style defects to due naming collisions
• Animations have wrappers instead of using confusing animation classes
• Bindings are simple because they’re just an array of strings vs. the different kinds of bindings in Angular/AngularJS
• Built in directives to ensure HTML stays logic free
• Developer tools maintained by core team. I can’t emphasize enough how awesome these were; dare I say they’re even better than React Developer Tools.
• Watches data changes instead of relying on digest calls being littered everywhere

The Gray Area:

These are more personal preferences, but I found I was tripping over myself occasionally. Here are a couple things some people say are positives, some people don’t like them, and I found them a bit questionable:

• There are multiple ways to do the same thing. This makes it difficult to choose conventions, and makes learning material a bit confusing. Whether it’s JSX vs Pug vs HTML for templating, @clickvs v-on:click for event binding, or the :prefix vs v-bindin HTML attrs, it can all be very disorienting when learning
• Feels similar to Angular. This could lead to a false sense of familiarity, e.g. thinking features behave the same way between Vue and AngularJS
• No state in the Vue router

The Bad:

Unfortunately not everything is sunshine and roses in vue-land. Here are a couple of the areas I thought Vue struggled or was lacking:

• Using Vue components inside existing AngularJS seemed a little overcomplicated. While there’s an Angular shim to easily use Vue components in Angular, it has several caveats which make it error prone
• Not a ton of blog posts about Vue (at the time I was researching)
• Because of single-file components, compilation of those .vuefiles is pretty complex. Could end up being a big headache and single point of failure for any infrastructure teams. Not saying it’s a problem now, but as someone on one of those infrastructure teams, the concept definitely made me squirm a little
• Not as mature. As you can see from Stack Overflow Trends, Vue’s level of adoption is quite a bit lower than React and Angular, although it’s an up-and-comer for sure

• Fake HTML elements/attributes in .vue files feel very strange. It feels like it’s fighting against the current ecosystem of having different compilers apply to different file types, a technique which I don’t see any real problem with.

How We’d Migrate

Given the difficulty of mounting Vue components in an AngularJS application, the easiest and least error prone way to integrate Vue into our app would be to do feature slicing. Reducing the amount of interfacing between Vue and AngularJS would be best, and would yield the least friction for the developer migrating or writing a component.

The Bottom Line

While Vue does have some interesting differences in comparison to AngularJS, namely the lack of features that could prove dangerous such as two way data binding, there are some key areas where Vue is lacking. Namely, 1/ The community backing just isn’t there, 2/ it tries to recreate the wheel in multiple places, each of which can trip you up, and 3/ it doesn’t seem to be very popular among candidates and companies currently in the US.

As for using it at VTS specifically, there are a couple other barriers. As I mentioned it could be painful to migrate, and in addition, the library options to interface between AngularJS and Vue are pretty unpopular, with no more than 200 stars on GitHub.

Vue would definitely put us in a better place than where we are now, but there are other options with similar feature sets that do not have the same flaws and could provide easier migration paths.

Angular 2+ (Not AngularJS)

Angular 2+ was released in September 2016 as a successor to the widely adopted AngularJS. We decided to treat Angular as a separate framework from AngularJS because although Angular is technically a successor to AngularJS, it is a fundamentally different framework.

The Good:

• Better supported by Google than AngularJS
• Discourages two way data bindings
• Can declare stylesheets with a component

The Gray Area:

• Typescript. While Typescript does offer some really great features, our current AngularJS app is on vanilla JS and it would be quite a big lift to move to Typescript and train our team on strongly typed language programming practices.
• Differentiation of data passed in and actions passed in. Cool idea but ultimately doesn’t provide much value and feels like unnecessary overhead
• ngCli, a command line tool for generating boilerplate files, is great for greenfield projects. But it’s also worrisome that a CLI is needed because there is so much boilerplate
• There’s a UI-router for Angular 2, but it doesn’t seem very popular

The Bad:

• Lots of boilerplate means potential for user error and wasted developer time, e.g. ng modules, inputs vs outputs, services, providers, etc.
• There’s an ngUpgrade utility, but our app doesn’t meet the criteria to easily use it
• Need to convert all directives to components
• Need to change the way we bootstrap the app
• Use of decorators is a bit confusing and still not common practice in javascript (the feature is currently in stage 2 of the tc39 proposal process)
• Still augments HTML which translates to custom conventions for differentiating behavior from standard HTML behavior. E.g. how you declare binding types with () and []
• They renamed bindings to inputs. This is incredibly confusing, provides no differentiable value, and makes it very difficult to search for on google/stack overflow/etc
• ngCli is useful but too opinionated for our usage. We’d have to augment our current build architecture significantly to make it work
• Very few examples not in typescript, so we’re kind of forced to use it
• Component definitions and usage is just as strange as in AngularJS

How We’d Migrate

While there is an ngUpgrade tool that converts the syntax from AngularJS to Angular, the work we would have to do to get our app in a place where we could do that is pretty much the same as migrating to any other framework. At that point it is mostly just copying and pasting and changing how bindings are consumed, but it would be a pretty big lift to get there.

Besides ngUpgrade, because of the complexity of managing our current AngularJS libraries and upgrading them to a point where they can be used with both AngularJS as well as Angular, it would probably be best to only develop new pages/applications in Angular moving forward.

The Bottom Line

After attempting to make Angular and AngularJS play nice with each other, we found that the work we would have to undertake to change how our app behaves so it abides by the new rules in the world of Angular would effectively be a full rewrite, and as laborious as using any of the other options.

Given the pros/cons of Angular, it’s hard to recommend over the other options. Though its architecture has evolved and become more like the other options we reviewed, many of issues we have are pretty core to Angular itself. In addition, there aren’t any benefits that we’d get upgrading to Angular over choosing a different framework that has better community backing, fewer impositions, and more curated best practices.

React

React is a library which focuses on making view components easy to create/maintain. Released in 2013, it’s arguably the most popular ui library in the last 3 years. It’s championed by dedicated development teams within Facebook/Instagram. Concepts such as component trees/virtual DOM, one-way data flow, and JSX were made popular by this library.

The Good

• Very little boilerplate and easy to learn. It’s almost all … just javascript (as opposed to the compiled or interpreted HTML of AngularJS/Angular/Vue)
• Because it is all in pure JS, you can leverage compile-time error messaging to let you know when your JSX is malformed
• Data flow is only 1-way which makes it very clear how data gets updated.
• Component tree performance is way better than the DOM manipulations + dirty checking in AngularJS
• Transclusion is super simple because all nested markup is in the children property
• Rendering inside an AngularJS app only requires 1 method call. It’s dead simple, and is pretty much the same as rendering a react app onto a standard webpage
• While migrating, it can use the same technique to binding to props as in an actual react app
• Well curated AirBnB linting guide for react apps
• Tooling is well maintained.

The Gray Area

• There’s a cost to learning JSX vs HTML templating
• There’s a UI-router for React, but it doesn’t seem very popular

The Bad

• Template conversion from HTML to JSX will require a bit more forethought
• No named transclusion slots. We’d have to convert multi-slot transclusions into components

How We’d Migrate

Given that React can interplay quite smoothly with AngularJS, we could go with one of two strategies:

Bottom Up

We would identify the most nested component on a given view and start converting up the tree until all of the view is in React. This would allow us to continually merge/deploy as usual since React components would live inside existing AngularJS views.

Page by Page

A new route that points to a React container component will be made. Inside that container component we’d rebuild the page using React components. We’d be able to side-by-side compare the Angular version and React version

The Bottom Line

React offers simplicity and interoperability which lends well to using it side-by-side with AngularJS. There’s a clear path in migrating to React incrementally with plenty of online guides offering advice. The cost we’d be paying down would be training the engineering team in how to composing JSX elements, how React lifecycle hooks differ from AngularJS’s, and how to craft components using true one-way data flow.

Ember

Ember is the most mature out of the bunch, being released in 2011. It was created by Yehuda Katz, a very prominent developer in the Rails community. It’s a full-fledged MVVM framework similar to Angular in terms of scope, offering solutions for routing, services, templating, and components.

The Good

• Solid how-to guides for beginner ember developers
• Testing is built into the framework

The Gray Area

• It’s a very opinionated framework. If you don’t opt into all of their suggested tools e.g. Handlebars templating/Ember data, there will be less support for solving bugs
• Not so great documentation. There are a lot of guides, but those aren’t really a replacement

The Bad

• Difficult to integrate into existing applications
• Uses much older patterns, harder to find relevant examples
• Requires changes to our back-end to work with ember data

How We’d Migrate

It’s difficult to say that there’s any incremental migration strategy. Ember is a very opinionated framework in general, and embedding it inside of another application is definitely outside of its comfort zone, and we found it incredibly difficult to integrate into our current ecosystem during our investigation. Any sort of migration effort would involve large scale rewrites.

The Bottom Line

Ember isn’t a viable framework solution to migrate to from our AngularJS app. The requirements to migrate are too large in scope to consider.

Bottom Bottom Line

Out of all the frameworks we evaluated, VueJS and React were the quickest to understand and get up and running. We struggled with Angular and Ember as there was a lot more convention to wire everything up and the documentation wasn’t as well organized and was often excessive to the point of unusability.

VueJS offers some of the familiarity of AngularJS templating paired with a similar reactive DOM system to React. The templating however comes at the cost of learning the framework’s unique caveats and intricacies. There is a large surface area to Vue’s API, leading to a steeper learning curve, slower development cycles, and unnecessary tribal knowledge.

React’s value comes from its simplicity. Their focus on a minimalist API and dedication to the functional school of thought yields a library that is powerful, yet easy to understand and use. In addition, data can only flow one way and is truly read-only; there’s less magic to it. Although there is more work when wiring “two-way bindings” up, it’s explicitly clear how data gets updated and how changes to data propagate.

The benefits of React far outweigh its shortcomings, and can help us solve some of our most prevalent problems such as updating data in real time, the massive memory footprint our app currently leaves, and the prolonged developer cycles spent dealing with AngularJS’s quirks. We have strong confidence that our engineering team can learn the ins and outs of React much faster than all other frameworks we evaluated.

Given all of these factors, the recommendation from the front-end platform team for the next framework VTS migrates to is: React.

After finishing this process towards the end of last year, we feel confident with our evaluation of the potential options and our final decision, and are excited to see where this choice in technology takes us. In the coming months we’ll be reporting back on our actual migration strategy, any potential speed bumps that are bound to come up, and the journey that will be training our team on this new technology. Stay tuned for more updates!

Footnotes

¹ Shout out to Grubhub, 500tech, Web.com, WayUp, Didjatv, AwesomenessTV, Stitchfix, Solar Winds, EERO,