Decoupling a CMS: choosing between Angular and React
Content as a Service, Decoupled Content Management, Headless CMS. All of these topics have been actively discussed in conversations about content management these past few years.
The eZ Blog is full of great insights on how to strike a balance between a decoupled and integrated CMS as well as the opportunities and challenges offered by Content as a Service. Despite all these resources, choosing the correct front end architecture continues to be tough, even for professionals.
As the terms imply, decoupling from a CMS allows for an open relationship between the back end serving your content and the front end displaying it. eZ has a comprehensive open REST API, so this is something that has been feasible for a number of years. One thing that is often overlooked is that decoupling from a CMS makes the front end architecture even more of a strategic investment.
A high level introduction to Angular and React
As mentioned, there are countless options for front end frameworks and libraries on the market. To keep things tangible, we'll focus on the "big two" that make up for the largest portion of the mindshare: Angular and React. In essence they enable developers to create sophisticated web applications that run in the browser, but have some key differences that are worth considering.
Both of these are Open Source projects that have a large corporate sponsor: Angular originates from Google and React from Facebook. This is important for the long term as the large investment the companies have made them ensures the longevity of the projects. In addition both have a vibrant community around them that guarantees a large pool of skilled developers at a global scale.
The biggest philosophical difference is that where Angular is a complete solution, React is a component that needs other components to make up a complete solution. In developer jargon the respective terms are Framework and Library. Both approaches have their pros and cons.
The framework approach of Angular enables developers to have a unified toolkit at their disposal. This means that a developer versed in Angular can expect any project to have similar tooling and concepts in place. The downside of this is that you are quite coupled to the direction of the framework as a whole.
The library approach of React allows developers to mix and match components to their liking. With great power comes great responsibility and when going with React you put a lot of faith in the original developer team. There are a lot of de-facto libraries that are now commonly used with React, but to this day it's impossible to say what "a React project" actually consists of and how it was built.
It's important to understand that neither approach is superior to the other by definition. Sourcing Angular developers is potentially easier for a larger project, where as the freedom of React allows gradual change better than Angular. Following up on selecting Angular, I would actually suggest to start new projects in the upcoming Angular version 2, because development of Angular version 1 will wind down soon enough.
On the downside large scale changes in Angular can lead to large version migration projects, where as going with React can result in a boutique product that is essentially completely custom. This can lead to a vendor lock as changing suppliers can come at a significant overhead in the form of learning the bespoke application structure.
When selecting vendors and deciding between Angular and React, it's best not to make the decision on technology alone. The vendor's proven ability to deliver in the technology is key and a good working relationship is key to any successful technology project. Being aware of the high level technical concepts helps decision makers make informed decisions
And even as the front end technology landscape is stabilizing, you should brace for change. Do you have a favorite technology when you go headless with eZ? Let us know in the comments section below!