React Discovery Days

Dev Diary

At Fusonic, we mainly use Angular to develop web applications. Since React is one of the most popular JavaScript libraries for web development, our Angular devs should have the opportunity to get to know React as well. That is why Fusonic organized the React Discovery Days. Two days where anyone curious enough had the opportunity to learn the basics of React or explore previously unknown concepts to get further acquainted with the library.

Michelle Weber
16. März 2022
8 Minuten

What did we do?

We did not have to start completely from scratch, as we could use the backend of an existing customer project. Also, one of our React devs set up a simple React project with the main libraries pre-installed as well as some examples of how to use the router, forms and state management. Based on this, we essentially re-implemented the front-end for the existing project. For doing so, we got a feature overview with some simpler and some more complicated tasks, as well as the UI designs. All of the participants worked their way through the feature list on their own. For a regular information exchange we could use the dedicated Slack channel as well as the arranged exchange point meetings where we discussed problems or topics that we were interested in. Throughout the Discovery Days, our most experienced React developer was available to help us out if we were stuck and to answer our questions. At the end of the two days we met again to showcase our final product and to exchange our experiences with React.


The outcomes

In this section, the thoughts, opinions and conclusions of all participants are summarized and grouped into themes to get an idea of what our experience with React was.

Build/Hot reloading
React shines with extremely fast hot reloading as well as with incredible tiny and quick builds. Another point to be considered as an advantage and disadvantage at the same time is that the console is not cleared between reloads. On the one hand, you can continue where you left off but on the other hand, it can be confusing to find out if a bug has been fixed or not.


There is the general impression that there are more libraries available for React than for Angular. Also, the React equivalent (MUI) to the at Fusonic widely used Angular Material UI library is nice and it seems to have more to offer than Angular’s implementation. One specific problem with React libraries is that there is no standard. No single organization "manages" all the different libraries. As soon as you look away your code is already deprecated, because some library author decided to change something. This can result in huge breaking changes in common libraries like the router lib that seem to be arbitrary and not really justified (for example renaming “Redirect” to “Navigate”).

Flexibility of React

React is extremely flexible since you can use whatever library you want (for e.g. state management). But with great flexibility comes also great responsibility. The huge flexibility can be the source for various problems. For instance you could easily be led astray with the great variety of libraries to use and with version compatibility. Moreover, the community seems to want to reinvent the wheel over and over again, which can confuse you a lot if you are a React beginner. Also, the many ways to implement things do not make it any easier to get started with React.


The indexed routes from React have been experienced as a nice feature, while protected routes did not seem to be as straightforward as the guards and resolvers in Angular. It feels a little bit hacky if you are not familiar with React and if you do not know what the proper way to implement the solution for this is.


The way to redefine the default units of CSS properties, like changing default “no unit” for line-height to “px” can be a nice approach for new projects. It might be difficult to change it in an existing project since the chance of missing a property is high and this can result in unexpected behaviors. Another advantage is that responsiveness does not take too much time for implementation. On the downside, the style bleeding is a nightmare in comparison to Angular’s style encapsulation. Moreover, there is nothing similar to “ng-deep” to e.g. override stylings but this might also just not be the “React way” to something like that. The styling of components with JSS also seems a bit unnatural if you are used to CSS or SCSS, and on the first glance it does not seem to have any advantages over styling with CSS or SCSS. For some it was  a bit difficult to understand if you are using it correctly.


Some other major downsides have been experienced when it comes to the React community as well as the documentation of various React libraries. The community seems to be all over the place. There are many tutorials and guides, often written by people who do not seem to have used React (including all the libraries you need to develop a real world app) in a big application yet. This and the many possibilities to implement things makes it hard for a beginner to differentiate if a proposed solution is actually good. There is a high chance that what is explained is not the right way to do something. Furthermore, there is a lot of outdated documentation, tutorials or examples. This is also a consequence of the extensive changes in the libraries and makes it even more difficult to find a good solution, since half of the examples do not even work anymore.


Redux is a state management library that is used heavily in our Angular Projects. For React you have the possibility to use the Redux Toolkit which should support using Redux in your React application. In the beginning it was difficult for some participants to figure out how the Redux Toolkit pattern works. On a first glance it seems to be just a lot of complex code and it is hard to say what is really going on. But after a while it made more sense - you just need to get used to it. Another advantage are the hooks you can use in Effects. The “onPending”, “onFinished” and “onFailed” hooks make the Effect tidy and spares a lot of boilerplate.

React Concepts

There are some React concepts that you cannot find in Angular. Some of them were perceived as neat while others caused struggles. While the mindset shift to functional programming came with some struggles and the life cycle hooks from Angular were lacking, the one-way data flow concept as well as the pure component structure are seen as advantageous. Also, Angular’s modules, services or dependency injection did not lack so far. For some, React still feels a bit like “free-for-all”. You never know if you are structuring things correctly and it does not feel opinionated. In the past, the class-approach for writing components was the way to go, which felt more similar to Angular. Now, the functional approach is the way to go which felt a bit alienating in the beginning. If you stop comparing it to Angular (which makes no sense anyway) it appears to be advantageous as well.

When to use React

The general opinion on when you should use React is primarily when you want to implement a small app or when you want to quickly create a single pager. As soon as  the application grows larger, it can get very complex since it is so unstructured and you need more libraries with more complexity. This way,  things can get out of hand quickly and suddenly it is not that easy anymore to get started with React. Moreover, there seems to be a general disregard of  backward compatibility. In comparison, most of the solutions for Angular 2 are still usable today - or at least guide you better for upgrading.  



Lilla (Front-end Developer, Angular)
“I didn't fall in love with React, and I don't hate it either. I don't understand the flat learning curve everyone is swarming about, but maybe we started with a complex application. But on the other hand, why start with less, if these are our everyday requirements?”

Marc (Front-end Developer, React)
“All in all it has been a great two days to discover more in depth things about React. I still enjoy working with React a lot, but I'm not afraid to keep learning Angular and working on a project for Fusonic. From my point of view it's more a thing of getting used to a specific framework or programming language, because all of them have their pros and cons.”

Gabriel (Front-end Developer, Angular)
“I’d be willing to use [React] with the proper guidance from someone more experienced”

Arjan (Back-end Developer, PHP/Symfony)
“If you are experienced with the ecosystem and know which libraries are good and which ones are "bad", it can be a great choice for an app. But by no means is React easier to get into than an actual framework like Angular. This comparison should not even be made, it's like comparing a kitchen to a complete house, that makes no sense.”

Kamran (Front-end Developer, Angular)
"I think React makes doing smaller tasks easier and complex / bigger apps more complicated because it's less opinionated, whereas Angular makes doing smaller tasks complicated and complex / bigger apps easier as you are forced to follow best practices from the start."

Michelle (Front-end Developer, Angular)
“To put it in a nutshell: I don’t like React so far but I also don’t hate it and with the guidance of an experienced React dev I’d be willing to try it out on a small project.”

All in all, the React Discovery Days have been a success and everyone could take away some insights and new knowledge as well as form an opinion about React. It certainly has its pros and cons like any other library or framework, but some of the participants may still be willing to use it in future projects. 💪

Mehr davon?

Cut to the chase What is an SSR app
Dev Diary
Cut to the chase: What is an SSR app?
25. April 2022 | 6 Min.
Pixel-perfect frontend
Dev Diary
The pixel perfect front-end
20. September 2021 | 4 Min.



Wir schützen deine Daten

Wir bewahren deine persönlichen Daten sicher auf und geben sie nicht an Dritte weiter. Mehr dazu erfährst du in unseren Datenschutzbestimmungen.