Key Takeaways
- Consider the size, flexibility, offline support, server rendering, and maturity of a front-end framework when choosing one for your company.
- Hands-on experience with the framework is important. The author’s team built authentication screens with Aurelia and React to evaluate them.
- React was chosen for its maturity, community support, and ease of hiring. Angular 2 was eliminated due to failing most of the selection criteria.
- Vue and Aurelia were close competitors, and would have likely served well given the requirements. However, hiring experienced developers was a significant factor in the decision.
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.
Taking into account the hard deadline we had set for delivering the project, I led an evaluation of a range of front-end JavaScript frameworks. The opportunity to make this level of change doesn’t often present itself in major corporate projects so we tried to be as thorough as possible in the evaluation process.
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.
Flexibility
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.
Offline Support
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.
Light Weight
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.
Server Rendering
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.
Maturity
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.
Other Features
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.
Hands On
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.
Result
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.
This article was peer reviewed by Stuart Mitchell, Ralph Mason and Vildan Softic. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!
Frequently Asked Questions on Choosing the Right Front-End Framework for Your Company
What are the key factors to consider when choosing a front-end framework for my company?
When choosing a front-end framework for your company, you should consider several key factors. Firstly, consider the project requirements. Different frameworks have different strengths and weaknesses, so it’s important to choose one that aligns with your project’s needs. Secondly, consider the learning curve. Some frameworks are easier to learn than others, which can impact the speed of development. Thirdly, consider the community and support. A strong community can provide valuable resources and help when you encounter problems. Lastly, consider the performance and size of the framework. A lightweight, high-performance framework can lead to a better user experience.
How does the size of a front-end framework impact its performance?
The size of a front-end framework can significantly impact its performance. Larger frameworks often come with more features and capabilities, but they can also be slower to load and run. This can lead to a poorer user experience, especially on slower internet connections or less powerful devices. On the other hand, smaller frameworks are typically faster and more efficient, but they may lack some features or capabilities. Therefore, it’s important to balance the size and performance of a framework with your project’s needs.
What are some popular front-end frameworks and their strengths?
There are many popular front-end frameworks, each with its own strengths. For example, React is known for its virtual DOM and high performance, making it a good choice for complex, dynamic web applications. Angular, on the other hand, is a full-featured framework that includes everything you need to build a web application, making it a good choice for large-scale projects. Vue.js is known for its simplicity and ease of use, making it a good choice for smaller projects or for developers new to front-end frameworks.
How important is community support when choosing a front-end framework?
Community support is very important when choosing a front-end framework. A strong community can provide a wealth of resources, including tutorials, documentation, and forums where you can ask questions and get help. In addition, a large community often indicates that the framework is popular and widely used, which can lead to more frequent updates and improvements.
Can I use more than one front-end framework in a single project?
While it’s technically possible to use more than one front-end framework in a single project, it’s generally not recommended. Each framework has its own way of doing things, and mixing them can lead to confusion and complexity. Instead, it’s usually better to choose the best framework for your project’s needs and stick with it.
How does the learning curve of a front-end framework impact project development?
The learning curve of a front-end framework can significantly impact project development. A framework with a steep learning curve may take longer to get up to speed with, which can delay the start of development. On the other hand, a framework with a gentle learning curve can allow you to start development more quickly. However, ease of learning should not be the only factor in choosing a framework. It’s also important to consider the framework’s capabilities and how well it fits with your project’s needs.
What is the role of a front-end framework in web development?
A front-end framework plays a crucial role in web development. It provides a structure for the code, making it easier to maintain and scale. It also provides pre-written code for common tasks, speeding up the development process. In addition, a front-end framework often includes tools for testing and debugging, making it easier to ensure the quality of the code.
How often should I update the front-end framework I’m using?
It’s important to keep your front-end framework up to date. Updates often include bug fixes, performance improvements, and new features. However, updating a framework can also introduce changes that break existing code, so it’s important to test your application thoroughly after an update. As a general rule, you should update your framework as soon as a new stable version is released.
How do I decide between a monolithic and a micro front-end framework?
The decision between a monolithic and a micro front-end framework depends on your project’s needs. A monolithic framework provides everything you need in one package, which can simplify development but may also include unnecessary features. A micro framework, on the other hand, provides only the basics, allowing you to add only the features you need. This can lead to a lighter, more efficient application, but it can also require more work to set up and maintain.
What are some resources for learning more about front-end frameworks?
There are many resources available for learning more about front-end frameworks. Online tutorials, documentation, and courses are a great place to start. Websites like Stack Overflow and GitHub can also provide valuable insights and examples. In addition, many frameworks have their own communities where you can ask questions and learn from other developers.
Chris started out as a web developer when Netscape ruled the world and works as a Team Lead at Iress in Melbourne. He organises community groups Men Championing Change and Melbourne CSS. Aside from musical distractions and accumulating frequent flyer points, Chris and his wife Sarah can be found in the company of their small human.