How to Choose the Right Front-end Framework for Your Company
During an evaluation of our core web platform at Singapore-based employee benefits start-up CXA Group, we decided to shift direction away from the aging existing architecture and rebuild the front-end from scratch. One of the challenges of the platform is to create a web application that works well across CXA Group’s 12 target countries throughout Asia.
There was a lot on the line in the decision: with the exponential growth of our business, we couldn’t afford any missteps along the way. We also had to take into account the fact no one in the team had any significant experience in any of the frameworks we were looking at.
Narrowing the Field
New front-end frameworks seem to be published every day, so we conducted a meta-analysis to reduce the range of frameworks we considered. Including frameworks we had heard of, or had recommended to us, we were left with Angular 2 (heard of), Aurelia (heard of), Vue.js (recommendation) and React (recommendation).
We measured each short-listed framework against a list of key requirements to see how they ranked. Some of the requirements were based on what we knew we would need for the project while others were projecting forward to what we would like to do.
Our chosen framework would need to present a range of configuration options and be relatively simple to customize. Much of this seems to come down the architectural philosophies: making architectural decisions on your behalf or leaving them entirely open.
Angular 2 exists at the monolithic end of this with every choice (state server, router, handlers) made for you. The benefit of this is it’s very easy to get up and running quickly, while the potential cost is modules not working how you need them to and having nowhere to go.
React, Vue, and Aurelia are at the other end of the scale, offering the ability to swap in components as required. Aurelia and Vue have a key advantage over React with configurable boilerplates in their initial setup.
Like Vue, React itself only presents a small part of what you need to build something. From there, many decisions have to be made which is certainly daunting. In the time since React’s initial launch, various boilerplates (including React Boilerplate and Create React App) have been created to ease the introduction.
For our test React project, we decided to forgo any particular boilerplate and dive straight into it. We still installed a few, if only for reference code. This approach was certainly difficult but we learned a lot about each component in our React stack and felt more confident with the end result.
Vue and Aurelia won this round with their reduced learning curve and modular structures. React earned a partial credit for flexibility even though the initial setup is more notably difficult.
With APIs like Service Workers, the ability for web applications to function without a live or stable Internet connection has become a possibility. Within our team, we’ve not yet had much experience in this area and didn’t dive much deeper into it other than to confirm all the frameworks evaluated offer offline support of some variety.
The byte-size of code sent to the client makes a big difference in browser performance, both for bandwidth and processor time. As custom code and third-party libraries are added, the byte size can only get worse making it critical to start small. CXA Group’s target market extends into countries where bandwidth comes at a premium, so it is essential that we deliver as little code to our clients as we can.
In lieu of hard data reflecting production configurations, we looked at core library sizes to give at least some indication of what we would be in for. Actual production sizes are larger than shown here.
Vue’s developers have gone to great lengths to shrink their core libraries down to an impressive 23 KB. React and Aurelia sit somewhere in the middle (about 42 KB and 64 KB respectively) while Angular 2 is a remains a heavyweight pushing 143 KB (including RxJS for state management).
In practical terms, production builds of Vue, Aurelia and React are near enough to each other to be within consideration. Angular 2, once again, sticks out in the wrong way.
Early single-page application (SPA) frameworks followed the model of sending all code to the client. This means the initial rendering of the page is left for the client and, as a direct result, the initial page load is going to be slow. The concept of server-rendered pages in SPAs puts the burden on the server for the initial render allowing everything else to be lazy-loaded after that render.
Vue and React add server rendering with plugins. Angular 2 is currently merging their Universal feature into the core although the functionality doesn’t match what’s offered by Vue or React. Aurelia has server rendering marked as a feature in development but lacks a timeline for implementation even if it has other performance tricks up its sleeve.
In choosing a framework for an enterprise-level site, broad community support, stability and ability to hire are very important factors. It is difficult to speculate whether any framework will still be supported in three years but we decided to look at the current health or otherwise of each to make a decision.
Looking into the initial public release dates of the frameworks gives us some idea of how robust each is. In theory, at least, older libraries should have a better feature range and fewer significant bugs.
React wins easily here, with the first public release in March 2013. Although Vue was initially released in October 2015, it didn’t hit its stride until version 2 released in September 2016. Aurelia is a newcomer hitting version 1.0 in August 2016.
Angular 2 is interesting: it is significantly different from version 1 and, for practical purposes, reached its first release in September 2016.
Part of this aspect of assessment involved diving into the development history of each library beyond the release dates themselves. A long, stable development history – even in beta – certainly lends confidence.
Various team members had been watching the development of the candidate frameworks for some time which gave us at least some feel of the overall stability of each. Of all the frameworks we reviewed, Angular 2’s troubled development history stood out, with significant breaking changes and unclear release dates. The framework made it to the final release in the end, but it was certainly messy along the way.
The final, key aspect of maturity – reflected in the above – is the ability to hire experienced staff. Given our team’s limited experience in the frameworks we assessed and the aggressive timeline we were facing, we wanted to hire experienced developers.
Hiring with particular experience can be limiting, however, it certainly makes a difference on larger projects such as ours. We eliminated Angular 2 at this point since it failed too many of our previous requirements.
For the remaining frameworks, we first searched different job sites and ran separate job ads for each framework. We found no job ads for Aurelia or Vue, nor did we receive any applications. By comparison, we found several React jobs on offer and we received a number of quality applications.
The remaining features on our list – developer tools and unit testing support – are offered in all of the frameworks we looked at. Without solid developer tools, debugging is near impossible and unit testing is all but essential for enterprise-level applications such as ours.
No amount of theory is equal to hands-on experience. With that in mind, we chose two of the frameworks that met most of the requirements – Aurelia and React – and started coding in parallel. There wasn’t a strong reason for omitting Vue at this stage; we simply didn’t have enough time to spend evaluating.
The task given was to build authentication screens matching the basic functionality of our existing application: login, call to API and establishment of a session. Two team members were each assigned a framework and given a calendar week to see what they could build.
The Aurelia demo was more complete, in part thanks to the easier setup procedure. We did feel we had a better understanding of what was inside our React stack after the work that went into selecting each part. Aurelia still won hands down for ease of initial set up.
We were unable to draw any significant conclusions based on hands-on coding alone. Perhaps the only surprise was how similar the code was: much of that thanks to the structural changes introduced in ECMAScript 6 which is used by both frameworks.
Our choice, in the end, was React; chosen for its maturity, community support and ease of hiring above all other features. While React was the clear winner for our criteria, it was great to see such quality among the competing frameworks we looked at.
Vue and Aurelia proved close competitors for next in line. Vue comes out marginally ahead with a more complete feature list but either would have likely served well given our requirements. Had we not been pressed for time, hiring would have been less significant and we would have extended our hands-on work to include Vue.
Angular 2 disappointed by failing most of our selection criteria. For all its merits, it is clearly not for us.
Having chosen React and started building our project, we aren’t likely to perform an evaluation like this again anytime soon. As for you, what criteria would you add to our list? What did we miss that we could have done better? I look forward to your comments and suggestions.