For the past several years, ISL has been almost exclusively an AngularJS shop. Back when we made the choice to utilize AngularJS as our go-to front end framework it made sense — our clients wanted a lot of real-time data flows with tons of state on the client. AngularJS provided a wealth of functionality right out of the box. In addition, before standardizing, everyone was just sort of using whatever they liked, which led to an enormous amount of fragmentation and inconsistency.
It got to the point where you could tell which group of developers were working on a codebase just by which frameworks were included (and also which CSS grid was being used but that’s a story for a different post). By standardizing on AngularJS (insert any other framework here), we were able to draw focus, re-use more code and make code reviews practical. Yet, after a while, as client needs shifted and we brought on new developers, we began to feel the burden of three primary challenges.
Focusing too much on specific technologies and frameworks when thinking about hiring needs can quickly lead you down a path of ineffective technical evaluations. You may find a candidate who is great in framework A, but as soon as you need them to solve a problem outside the context of their specialty, there may be a disconnect. We prefer to focus on general aptitude, potential growth, problem solving skills, and a strong values fit.
We’ve found this to be particularly important when bringing on junior developers. Over time, we noticed a fairly significant barrier to entry in terms of independent productivity. Sure, we expect a certain amount of guidance when dealing with junior devs, but the amount of time it takes to become significantly (and independently) productive with AngualrJS in the way that our standards demand, was getting to be problematic. As great as AngularJS is, the documentation left a lot to be desired.
This is a big one. Even for our senior web developers, dealing with the entire framework regardless of how much (or little) you actually needed, was more trouble than it was worth. People were frustrated with unproductive discussions about factories vs services or where exactly a certain logic belonged…a directive? A service? Something different? How do you configure your app…constants?…values? How much contorting do you do before you decide you need to bring in the actual jQuery library as opposed to AngularJS’s built in version?
As time passed we began to focus more on performance. And so, this idea of bringing in the entirety of AngularJS just for two-way data binding seemed silly. Managing state on the client also became a challenge, particularly when the data needs to remain consistent with data behind a remote API. Then there are things like the digest cycle.
It’s difficult enough to get developers to think about testing on the front end, but mocking components for a non-trivial AngularJS application can be absolutely mind numbing!
We decided it was time to wipe the slate clean and assess our needs and see what else the internet had to offer. The first choice was the obvious jump to the new version of AngularJS. We did look into AngularJS 2 but with no backwards compatibility and the introduction of TypeScript as the recommended language, it didn’t seem like right choice. We figured if we were going to start over, we might as well see what else was out there. We evaluated Ember.js —Ember is actually quite impressive (especially with it’s built-in support for the JSON API spec) — but coming from AngularJS, we felt we would be best served not in the form of one big framework, but with a library that covers the most common scenario (component based UIs with JS interactions) and go from there.
React is a great library that really gives us the component-based workflow we desired (we actually experimented with React on one of our client projects). React also has a robust developer community, which gives us a lot of ready-made functionality, something really important for tight deadlines. However, the inclusion of JSX, was a hot topic. While the technology itself is fine, it makes it a bit too easy to cross that very fine line between the healthy coupling of component views and data and the inclusion of too much logic within templates. A senior web developer with years of experience will no doubt be able to navigate that space easily while maintaining the discipline necessary to check him or herself when views get out of control, but you run the danger of not drawing enough distinction between state and presentation. A failure to do so could be detrimental to the growth of a junior developer… and it’s for this very subtle reason we ultimately decided not to adopt React as our standard UI library.
This leads me to our final decision – Vue. It’s hard to overstate how much the team really enjoys Vue. It’s not just the development experience, the documentation is really great — I can’t stress enough how important this is from an onboarding standpoint. As you may have noticed, Vue and React share very similar outlooks on life (one of the reasons I personally like it). It takes the best things from React, and distills it down to just a few core concepts. There is even comparable state management in the form of Vuex. Sure, it doesn’t have quite the community of React or AngularJS, but what it lacks in raw devs hands, it more than makes up for in useful features, clear documentation, and most importantly…team fit.
Normally, when someone talks about team fit, it’s in the context of hiring. But when adopting a technology, team fit is just as important. The technology with which your team will spend the vast majority of their time can be seen as an equally important relationship to that of a coworker. We are constantly looking into ways to improve our processes and to make building beautiful, functional interfaces as easy as possible.
Vue allows us to follow our established practice of focusing on small, generic UI components that can be adapted to many different scenarios while not having new technologies introduced. Vue also provides a way to bundle components, which can be useful for large applications. The idea that we can use one framework that works as well with large applications as it does with one page micro-sites is great. Also, unit testing is plug-and-play. The library has solid support and is gearing up for great features like server side rendering. Heck, soon you’ll even be able to use JSX if you want. Is Vue a perfect solution? Of course not. It’s a solution that works for us and our current processes and that’s what’s more important.
This isn’t meant to be an exhaustive analytical post about the specific pros/cons to each of these frameworks (you can follow our engineering blog for those). Instead, I wanted to provide a rundown of how we adapt to shifting client needs and increased user awareness/sensibilities, while balancing our desire to tinker with the latest and greatest technology the web has to offer.
We have so many great things going here these days. If you’re interested in working with us, take a look at our current job openings and drop us a hello!