In addition to classical Desktop frontend technologies such as WinForms or WPF even large industrial companies can’t deny that there is an interesting movement towards web frontend technologies. As a UX company that also supports its clients in frontend engineering to a large extent, we are often asked whether web technologies fit their needs and if so which one to choose. Besides many relevant libraries and frameworks, the two predominant players are Angular* and React. The question which one to favor over the other is not a trivial one. It can only be answered through comparing up several criteria according to a set of defined developer requirements. In the following I will outline the answers we found at Centigrade, and that will be most helpful for our clients.
Why choose a web technology?
At first, we must answer, why it could be reasonable to use web technologies for frontend engineering at all. Deciding to do this because of famous buzz words or trends is not a good reason. However, this is often an initial motivation for this topic to arise. Web frontend technologies are a chance to develop systems that are truly cross-platform. This can refer not only to operating systems (like Windows or Unix) but also to mobile devices, and basically every system that runs a browser. Modern client-side web frameworks even go a step further by abstracting from the browser, which makes them able to target native desktop, mobile or even other systems. Focusing on the digital age and Industry 4.0, where several different devices are inter-connected, having this flexibility oftentimes is a strong requirement. Therefore, taking web frontend technologies into account is a valid choice. 
Angular and React
Angular is developed by Google, the company behind React is Facebook. Both are huge companies, the technologies have a very large community, and (in terms of web) a rather long and stable development history. After observing the evolutions over a longer period, we feel comfortable to say that both can and will be used in production.
The Angular and React core concepts are quite similar: Both are component-based, which means all applications are built by composing several small, self-contained components of clear responsibility to a larger system. As nowadays manipulating the browser’s DOM (Document Object Model) in a direct way is considered to be a bad practice in web engineering (see jQuery), both technologies are based on the idea of DOM abstraction. By declaring Angular and React components on the view level, you only describe what the application should look like, while the frameworks use sophisticated algorithms to process this information in the most performant way. Because of this abstraction of concrete browser DOM elements, it is possible to natively target other systems such as Android or iOS, backend servers or even IoT devices. Engineers behind both technologies work very hard on many levels to improve performance, architecture, flexibility, and the developer experience for others. To sum up, if each technology is used as intended, both meet the multi-platform requirement.
Framework and library
As the core concepts and these technical key points are very similar, let’s focus on the differences between Angular and React to argue for or against one. The main difference is that Angular is considered as a framework or even platform, while the React core is considered a library. As the term already states, a framework serves a frame for the application code to fit into. This means there are a lot of predefined constraints like programming languages, tools, or patterns you should stick to. In contrast to that, a library can be used by application code in a more flexible way. You can choose to use React only in some places and you must add missing parts by your own at some point. This flexibility has pros and cons.
Angular is very opinionated, it is more restricted, and it is harder to break out of its frame. On the other hand, it comes with a lot of already established best practices, which reduces the burden of decision making before getting started. It can be easier to integrate or adjust React to fit into already established tool chains. However, you are even forced to do this integration by yourself and to choose proper tooling where the library makes no recommendations by itself. This could be a bit overwhelming, especially for newcomers or in very time critical projects.
Fit into an established toolchain given by Angular as a framework vs. freely adopt React as one of many libraries into your codebase.
UX process based decision
As our goal was to highlight our favorite approach, we will take a brief look at the specific decision criteria that arise from the viewpoint of frontend engineering, which is key in the domain of UX consulting.
Centigrade Design Engineers closely work together with the client’s backend engineers and are focused on a proper way to handle a large amount of look and feel resources for an application. Even in smaller projects, there will arise a lot of CSS styles and classes. It is crucial that this style information can be modularized, reused, and structured in a well maintainable manner. Moreover, structuring of styles must not affect the performance in a negative way. In addition to the creation of static style information (the look), it is important that we can engineer the component’s interaction and layout-behavior (the feel) just the way they have been specified in prior conceptual and visual design steps. Both aspects, the look and the feel, must work well in collaboration with the client’s backend engineering. There is a strong need to clearly define interfaces where the frontend and backend meet each other so that team members can work in parallel without blocking each other.
Styling Angular applications can be done in a very well-structured way by using SASS and a combination of global and component-based style information. There is no clear path or a single best practice on how to style React apps, yet. Styled Components, CSS Modules and other techniques compete against each other.
A lot of our own and the client’s engineers have a strong C#/WPF background. Building Angular applications in a rather classical MVVM/MVC-like way seems more natural than following a functional way of programming in React with a strong focus on immutability. While both patterns have their pros and cons especially web newcomers (with a .NET background) may encounter a steeper learning curve in React.
The Angular platform does not only come with TypeScript (which we love especially in team collaboration for its predictability), the Angular CLI, and a lot of other helpful dev tools integrated but also with great documentation and a well-written style guide directly embedded in its toolchain. When choosing React you must make a lot of small decisions when it comes to defining your toolchain, e.g. using TypeScript in React requires additional steps as usually Babel is used as JavaScript transpiler for React.
Choosing React puts you in charge of evaluating, deciding, and committing to a set of additional technology decisions in collaboration with the client for every single step of your toolchain. It requires a lot of initial, additional work before you can focus on developing the actual application. If there is a need to have fine-grained control over these pieces – which is mostly the client’s decision – this is necessary and preferred in React. It is possible but not preferred in Angular, too.
Conclusion
To conclude with our special decision criteria in mind, at Centigrade we have a preference to use Angular as our main web engineering technology for its high level of integration and productivity. Angular as framework will be a good choice if you are looking for a rigid solution with a lot of pre- but well-defined parts. It comes with extraordinary tooling and an awesome community. React as a library may be a better fit for you if you want to be in total control of every bit and piece from the very beginning. So, we don’t advise against working with React in general. We simply had very good experiences with the Angular platform and almost no barriers realizing even complex, large-scale projects. We embrace new technologies like Angular and React as long as they enable us to develop products that provide a great UX and make the users happy.
If you are curious about in-depth technology discussions and you have more questions about how to design and implement for great UX, feel free to check out our Engineering Services website.
*When talking about Angular, we refer to Angular later than version 2 (currently 5). Angular prior to that, Angular 1.x, is also called AngularJS. We therefore follow the official terms promoted by Google.
