Our approach to evaluating the frameworks
Technical strengths and weaknesses of the options
Findings specific to each framework
Download a free PDF version of this guide.
Over the last several years at Intelliware we have had significant success developing rich web interfaces using AngularJS (also referred to as Angular 1.x). Angular 2 has arrived at a time when other frameworks such as ReactJS and Polymer have also grown in popularity and our clients are asking us what the best path forward is or to recommend the best fitting web UI technology for their specific situations. And we need to understand and build capability in the popular frameworks of the future recognizing that Delivery matters and frameworks’ popularity and promises of technical improvement and better developer experience must be balanced against maturity, robustness, and support.
In this paper we share some background on the frameworks, our investigation approach and our observations and findings. Not surprisingly, there is no silver bullet. The needs of a small development shop creating a single application differ from those of large enterprise development teams so we also provide some high level conclusions on which frameworks may be more appropriate in certain situations. We’ve kept our discussion general and tried not to go too deep technically in this paper. We’re happy to discuss our experience in more detail upon request.
Our primary interest was “Developer Experience” and so as we built our core functionality in each of the three frameworks we evaluated documentation, ease of setup, and learning curve.
Which framework is best for the job?
All three frameworks that we investigated have backing from large corporate players and are likely to succeed to varying degrees and in applications that play to their strengths. These large corporations participate on boards like the W3C which is standardizing on Web Components. We believe this influence will lead to convergence of framework capabilities especially on the components front.
Given that the three frameworks we investigated all follow a component-based approach, we found the code was similar no matter which framework we chose. We also found that creating a robust project build pipeline was as important to developing a successful application as the framework itself.
Somewhat surprisingly, creating the build pipeline was not an easy out-of-the-box process for any of the frameworks. We expected a build pipeline to be available and ready to use, and finding up-to-date documentation was challenging.
Angular 2 has improved its upgrade path to current and future releases making it an easy choice to migrate existing AngularJS applications. Polymer and React are great for creating components and those components can be used interchangeably and even be embedded into Angular applications. Polymer with its focus on supporting emerging standards and leveraging Web Components will likely have a significant impact on the development practices over the next several years.
Overall, our experience was that Polymer is more productive, easier to understand, and reasonably straightforward to get up to speed on compared to the other two frameworks. Web Components will grow in importance. Polymer will continue to grow, and the other frameworks will improve their support for Web Components.
ReactJS is very popular due to its light footprint and customizability. Still, based on our experience in the field and in our research we believe that both Angular 2 and Polymer will play a bigger role in the future, especially in enterprise development.
Web Components Defined
The W3C is working to standardize Web Components, a set of features that allow for the creation of reusable widgets or components in web documents and web applications through HTML and DOM specifications.
Designed to improve component-based software engineering on the web, the model is to develop an encapsulated piece of custom code, known as a Custom Element, that is used to add a single UI element. The encapsulated code (JS, HTML and CSS) is an object that can interoperate with other elements and be reused throughout your applications. Changes made to one element have no impact on other elements.
Angular 2 was primarily developed by Google and Microsoft with the hopes of leveraging the Angular brand to replace AngularJS as the market leader. AngularJS originally began as a prototyping tool, so ease of use had a higher priority than performance, but eventually the framework became bulky and heavy to load. Angular 2 is focused on “production optimizing” the AngularJS framework but since the Angular team had to reinvent Angular, many of the patterns that existed in AngularJS are no longer supported in Angular 2. However, Angular 2 aims to improve speed and performance, although its size is still large due to its focus on developing enterprise applications. Angular 2 benefits from familiar IDE and testing support, a strong developer community and a regular six-month release cycle. Google also promises to focus on upgrade paths for both application and skills.
ReactJS is backed by Facebook and Netflix, among others. It focuses on building components although it doesn’t specifically enforce the Web Components specification. ReactJS is known for its lightweight approach and unlimited customizability due to coming with almost no native features. However, this is also a weakness as there are dozens of component libraries and tools you can pick from, leading to complexities and challenges in selecting consistent components and the possibility of incompatibilities. It has good IDE integration and testing support, and a large developer community to support it.
Polymer currently supports Chrome and Opera natively, as well as all evergreen browsers that don’t yet support Web Components by using polyfills from the WebComponents.js libraries. The ultimate aim is to use the emerging W3C Web Component specifications in order to build once for all web browsers. Although these standards are still evolving, some were recently finalized, prompting Google to begin developing Polymer 2.0 in order to be compliant. This evidence that standards are evolving, and perhaps settling, is allowing other companies, such as Firefox, IE, and Safari, to provide input and start becoming more involved. Overall, these are very positive signs for the industry.
How we investigated
Since a consistent user experience across an application is particularly important for large scale development, particularly when parts of a large application are being written by multiple, separate teams, the best way to achieve this is to build small, reusable components. We wanted to see if creating components in the three chosen frameworks could provide this consistent user experience and if any of the frameworks was more effective than the others. To save time and resources, we avoided building full applications and did not run performance tests.
1: Developer Experience (DX)
Our investigators decided to use Developer Experience as the metric for evaluating the frameworks. Developer Experience is a broad term that, for us, begins with the idea that since a developer constantly works with specific tools, a positive experience should translate to greater productivity. Each developer’s experience is subjective, but they can still judge whether a tool was easier or faster, and whether it met their needs.
The developers selected three criteria by which to judge the frameworks:
Documentation availability and quality
Was updated information available and correct? Was there an active support community? Were answers easy to find and did they fully explain the solution?
Set up time
Was installing the framework and all of its supporting tools easy and/or fast? Did the framework install as expected?
Ease of use and learning curve
Did the framework deliver on its promises? Can you accomplish what you need with it? How easy is it to learn? How quickly can an expert developer start using the framework effectively? What will a novice need to become effective?
2: What we investigated
We considered the typical applications we build in order to identify common tasks and reused elements.
The following were the investigative actions we took during this exercise:
Set-up a basic project for
Each framework, including setting up the developer environment and getting everything ready for actually writing the code.
Representing a detail panel (name, avatar, Birthday etc.), and a list view (to view multiple detail panels).
Embed a component
Inside another component (package and publish a component and use it in another component)
The developers began the framework installation and set-up process using default settings, then customized the various tools and dependencies in order to move on to the next task. In some cases, multiple attempts were needed to set up the frameworks successfully.
Part of the set-up step including assessing what documentation was available and its quality. If a developer could not find an answer after 20 minutes of focused searching, they decided the documentation did not exist or was inaccessible. If they did find documentation, they considered whether it was easy to understand and resolved the issue.
The investigators took turns working with the different frameworks and, as they completed each task, discussed and evaluated their experiences.
3: What We Found
The investigators evaluated their Developer Experience for each of the frameworks in the three categories of documentation, set-up, and ease of use.
Updated documentation and an active user community
Are essential for a framework’s viability, as they are the primary method of learning. However, we were disappointed when we found that all three frameworks were weak with regard to documentation. Not only is time lost searching for and not finding good documentation, the lack of relevant information leads to a high chance that any information and examples that are found will be erroneous or encourage bad coding practices.
It is possible to set-up Angular 2 and ReactJS with default options
However, if you have specific requirements or want to optimize your code or application performance, both frameworks suffer from the need to customize the developer environment, including dependencies and the build script and pipeline.The benefits you get from the additional control offered by customization comes at the cost of requiring too much set-up time.
It takes trial and error to find a combination of tools and options that work
With Polymer, this was much easier as this framework came with a well-designed Command Line Interface (CLI) that simplified set-up. As well, Polymer is following a methodology of relying on the browser to do the heavy lifting of implementing the new Web Component standards, which streamlined the set-up process greatly.
Setting up the build process was difficult
Knowing which tools to use to compile and transform the source code. There are suggested build tools for each framework but none works out of the box. Because they are so easy to create, there are thousands of tools and generators (a pre-packaged set of framework and build tools) available on GitHub. Most are copies of existing tools with slight alterations. No one has the time to evaluate all these tools so it is easier to take a prominent solution, adapt it to your specific need and abandon it when done.
Although all of our customization work may seem to be beyond the scope there were two contrasting reasons
First, the frameworks were either too bulky, like Angular 2, with libraries and functions not needed for a particular application or, like ReactJS, they came with zero native libraries or tools. Either way we had to tailor our build script to create ease-of-use. One of the keys to a successful project is investing the necessary time to set up your build pipeline in order to prevent errors and make your work easier down the line.
Interestingly, the teams developing these frameworks also acknowledge this gap, with both Angular 2 and Polymer implementing CLI projects to impose their own naming conventions and file hierarchies when generating project structure and build scripts. The most important lesson we learned: invest in your build pipeline.
Much like its predecessor, Angular 2 has problems with missing or outdated documentation. The rapid pace of Angular 2’s continuing development meant that writing and maintaining user docs has not been a priority. However, we are hoping this changes in the near future since Angular 2 has already had its full version launch and is now planning regular six-month releases.
We found that Angular 2 provides a broad feature set within a more defined environment, resulting in a heavier footprint than if they would have taken a more open, plug-in approach.
We noticed significant architectural changes from AngularJS, as well as a lack of straightforward backwards compatibility, and can see why this may cause some resistance to adopt and upgrade in the user community. Migrating your AngularJS directives to components can help.
ReactJS had the best documentation of the three and active community support.
For ReactJS, the customized set-up issue was compounded due to a very lean install, only allowing you to build the UI. For any other functionality (e.g. HTTP requests), you have to install build tooling and configuration elements or libraries. Since architecture decisions will impact which ones you choose, this makes it difficult to identify and plan for additional elements/libraries. All of our developers agreed that the process of selecting additional elements needs to be easier.
ReactJS’s staggering customizability is both a strength and a weakness. If you have a small application with very specific requirements, ReactJS is perfect because it can keep your code very light by pulling in only what is required. But the problem is that, in most situations, you want an out-of-the-box set-up that will let you start working as soon as possible. In enterprise projects, the large number of dependencies in ReactJS will create a lot of work, with the potential for component and upgrade incompatibilities. As well, early design decisions may restrict the types of changes you can make moving forward, while future maintenance and additions that modify the dependencies may introduce an unacceptable level of risk that will require added regression testing.
Due to a smaller user community, Polymer suffers from a general lack of documentation and support. This lack of a reliable source of information can be frustrating and could become a roadblock for novices.
After set-up, Polymer works immediately but it is more closed, meaning fewer customization options. For example, the recommended way to build with Polymer is to use the command line interface (CLI) that gives you two types of projects to build, either elements (Web Components) or applications. We were pleasantly surprised with the amount of support the CLI gives to building standalone components, something lacking in both Angular 2 and ReactJS. This makes it fast and easy to get started with Polymer, given its much lighter footprint, many existing components and CLI support.
Hybrid Approach Potential
After investigating the frameworks separately, the team then wondered if using multiple frameworks could work, by taking code and components built in one framework and using them in another. We called this a hybrid approach and were curious whether a component-centric approach would help us avoid framework lock-in. What did we find?
We were able to embed ReactJS and Polymer components into any framework. Essentially you can write your components in any framework you like and reuse them elsewhere.
To work universally, we recommend that you try to use an existing Web Component, if you can. If finding one proves difficult, we suggest you create a new one for your specific purposes. If this still doesn’t work, make sure that you follow W3C encapsulation standards as closely as possible. Not doing so may “pollute” your code base, making it much more difficult to debug issues. Staying close to the W3C standards will also ease migration, if or when that becomes necessary.
Not surprisingly, there is no silver bullet or one-size-fits-all framework solution. The most appropriate framework depends on your starting point and your destination. With the backing of large corporations, component standards are maturing and browser support for Web Components is becoming more important.
Given that the three frameworks we investigated all followed a component-based approach, we feel that the code you will write will be similar no matter which framework you choose. Creating a robust project build pipeline is an investment as important to successful application development as selecting the framework, regardless of which framework you select.
Based on the Developer Experience, we believe the demands of certain situations will make one framework a better choice over the others.
Angular 2 is a good choice if:
You are starting with existing AngularJS applications or experience.
You are building a large application and need a framework that will enforce consistent architecture across a large team or multiple teams.
ReactJS is a good choice if:
You are building an application that needs to update multiple views and states at a time.
Polymer is a good choice if:
You are starting with more junior developers.
You are building an application that does not have legacy browsers.
You are building an application that can make use of existing Web Components.
No matter what you decide, you will be creating components. As such, we recommend that you become familiar with the emerging W3C standards by using and perhaps writing Web Components when your target browsers support it.
These recommendations are a snapshot from November 2016 and our experience continues to grow in all of these frameworks and in different situations. Intelliware feels that every application with a rich web interface experiences different forces that influence its specific development, upgrade path, and framework selection. We would be happy to explore your application environment and future requirements with you and provide recommendations that will best meet your goals.
The Web UI CoE is a team of Intelliware experts that focuses on front-end technology. Overall, the goals of this team are to provide relevant insights on upcoming frameworks; create and distribute web components and tools; and help projects deliver faster by producing best practice and migration guides and propagating them throughout our delivery organization. The team members involved in this paper are Anson Chung, Gary Ng, and Jean Bourgeois.
Ready to turn a corner in your development journey?
Partner with Intelliware for IT Strategy, Enterprise Solutions, Agile Adoption Services, Fintech Platforming, Modernization Services, or Product Development.