In the ever-changing world of new technologies, obsolescence is never far away. In an instant, new, more efficient and effective tools leave the older ones far behind. Software developers cannot become complacent, relying on particular technological solutions; they must continually expand their knowledge and improve their competences to keep up with pace of change.

Have you ever wondered what motivates a programmer to switch technologies, opting for a brand new one? To find out, we interviewed Robert and Kamil, two developers who have recently switched from “old” to “new”. What does “new” mean, though? What decisions did they have to take and what do they think about them now?

We put these and other questions to Robert, who has chosen React, and Kamil, who has decided on Angular 5.

Tell us something about yourselves – how long have you been programming and what technologies do you use?

Robert: I’ve worked as a programmer in commercial projects for three and a half years. During  my studies, I became familiar with C#, Java, PHP, and JavaScript. JS was what I liked most and so I started to learn the AngularJS 1.2 framework. I watched the changes occurring in AngularJS 1.x and finished my adventure with it at the 1.5 version.

The main change in Angular 1.5, in comparison with the previous versions, was the addition of an option to build simplified directives, that is components. Initially, I wasn’t convinced. Only when I got to know React could I see the point and I started to implement Angular components in a commercial project. Also, Angular 1.5. and its components were helpful in making a swift transition to the new concept of Angular 2+. Currently, I’m using the React library.

Kamil: My experience with software development started at the beginning of my studies, that is over six years ago. It took me some time to find out which path I’d like to follow: desktop, mobile, or web apps. Finally, I decided to become a JavaScript developer. Looking back, I think it was a good choice, one that opened a lot of doors for me. I worked with Angular 1.x for two years and in that time Angular 2 was only mentioned occasionally, largely being discussed behind the scenes.

What made you work with React/Angular 5?

Kamil: Just like most developers, I love broadening my horizons, trying out new technologies – trial by fire. When a chance to create a project in Angular 5 turned up after I’d worked for a long time with the older version, I couldn’t resist it, I just had to take it.

Robert: I worked with AngularJS practically for three years. I had a brief encounter with React when I prepared an open workshop related to apps collecting info about air pollution. The data was gathered from an internal smog sensor and presented in an app based on React and Firebase. Working with React means building small and reusable components. This methodology of creating app elements appealed to me so much that I started to use components available in AngularJS 1.5, and not just directives.


Robert: I wanted our project to start using an ordered data flow through one-way binding (the possibility of moving the data in one direction, from the parent component to the child component, which provides information about the data changed in the child component), along with components, which resembles React to some extent. Rewriting the app was beneficial for the rest of the team: we could create new subpages quicker because we were able to use ready components. That was when working with AngularJS got too repetitive for me but, fortunately, I got the chance to try my hand at React. I took advantage of that opportunity and I’m really glad I did.

What, in your opinion, are the most important differences between Angular 5 and React?

Kamil: One of the biggest differences is the approach to storing HTML template codes. While Angular prefers creating them in separate files (which is not obligatory) in React you have to save them in JS files. Another major difference is that React is a library and Angular is a framework. As a result, Angular offers a lot of functionalities out of the box, whereas in the case of React, you need to import most of them manually, e.g. HttpClient or predefined filters and formatters (pipes).

Robert: Those who like storing HTML code outside of the JavaScript logic may be disappointed with React. It is possible, but the library itself doesn’t contain this possibility, unlike Angular. Importing templates from outside is complicated and personally, I prefer to adjust to the conventions of React. React is a library, meanwhile Angular is a complete framework. That’s why if you want to download data from API, in React you use the browser-supported Fetch API, and in Angular you use the built-in Http class.

What other differences are there?

 Another crucial difference between React and Angular is the method of data binding between components. In React, there’s only one-way binding, while in Angular you can choose between one-way and two-way data binding.

Certainly, Angular has a higher entry threshold than the conceptually simpler React. Angular has plenty of its own internal solutions. Additionally, it’s recommended that the code is written using the TypeScript language, which is a superset of JavaScript. This may be difficult in the beginning. On the other hand, React can be implemented with just knowledge of the older JavaScript language standard, ECMAScript 5.

What inspires you most in the new technology? Which elements do you find most useful?

Robert: What inspires me most is the possibility of using the upcoming standards of ECMAScript. Thanks to this, I can write modern code which will be maintained in the future. The forcing of data flow from the parent component to the child component feels safer when it comes to data flow between components in comparison with two-way data binding. Thanks to the one-way binding, I can control the complicated logic and relations between particular components. In more advanced apps and in work with larger amounts of data, Redux or Flow prove really useful (serving to manage the application state).

Kamil: In my opinion, the greatest advantage of the new solutions is their way of thinking about an app which they offer. The component approach combined with the Flux architecture significantly facilitates a way of designing and analyzing an app. By comparison, in a project with an older version of the framework, the component approach was propagated only in the 1.5 version – this gave rise to problems with distributed applications and difficulties in detecting potential errors and threats.

Has anything surprised you when you switched from the older version of Angular to the new one?

Robert: I have this funny story about my early days with React. Initially, I had a problem with selecting a library to communicate with an external API. In Angular, the $http service was available on the spot, serving to communicate with APIs. In React, there were many libraries – some worked better, some worked worse. I asked more experienced colleagues about it and learned that the best alternative is to use the Fetch API tool (used to communicate with API or download external resources) built into modern browsers. In older browsers, you can use the polyfill prepared by the GitHub team.

Apart from that, I wasn’t surprised by anything in particular, but I was really attracted to building apps basing on components. Graphic designers create their graphic projects of app on the basis of reusable components, so thanks to React, I can easily adapt to their work and quickly make new similar views. Actually, you can get similar results in Angular 5 or even in Angular 1.5, which supports developers’ transfer to a new level of thinking about application structure.

Kamil: I can’t say that anything surprised me in particular. I had to change my approach a bit and learn to use new tools but I don’t think anyone in the IT world would find that surprising.

What, from your perspective, are the biggest difficulties in changing technologies?

Robert: For me, the biggest difficulty was the change of approach that I’ve mentioned before: to building reusable components. In Angular 1.x, based on an MVC pattern, I used to create the logic in controllers, making use of services, and in the end I viewed the result in a template. In React based on Redux, I love the idea of storing data and app statuses. Ideal components only accept data to show it to the user and enhance user interaction. This allows the developer to speed up building new templates that visually resemble each other. Switching from the ECMAScript 5 standard was also quite difficult, but the newest ECMAScript standards let me write code in an easier and more pleasant way.

Kamil: For me, the biggest difficulty in switching to the new Angular was learning to use the tools suggested by the creators, such as RxJS (a library for reactive programming) and ngrx (optional – a library for managing application status, inspired by Redux) or the TypeScript language. The project I worked on was a traditional one. I mean, there was Angular and that was it. Only later on we could introduce Transpiler to the project: a tool used to convert the new standards’ code so that they could be supported by browsers which do not support them.

Let’s go back to the past for a while. Did the previous version of Angular offer anything so helpful and practical that you’re missing it now?

Robert: On my part, I can only say that I was kind of totally immersed in AngularJS so it was hard for me to get out. Definitely, the support of internal modules was very helpful, especially when I got to know them well. React, with the new standard of ECMAScript, opened my eyes and prompted me to widen my horizons, e.g. to learn more about Node.js.

Kamil: I think all the functionalities of Angular 1.x were covered in Angular 2-5. Sometimes, they differ in script or the way they work, but there is nothing I missed from the former version.

If you had an opportunity to work in a project using your interlocutor’s technology of choice, would you like to do that? And why?

Robert: Obviously, I’d be happy to accept such an opportunity because becoming more familiar with Angular 5 would allow me to evaluate the options of this framework and to better adjust technologies depending on the client’s needs. My self-development is also important to me – if you don’t test new technologies, not only do you close yourself off from the world in a way, you could use some solutions from a competitive technology to optimize your app for the end user.

Kamil: I’ve already dealt with React, but not on a commercial scale, so I’m no stranger to it. I’d be glad to get involved in a project using this technology, not because I consider it better than Angular but because I’m open to new solutions and I like comparing various libraries and frameworks.

Meet our colleagues

Kamil Mikosz is “determined and enthusiastic JavaScript Developer, focused on setting clear goals and self-development”. He loves spending time with his family and playing volleyball. You can read his last article: “How to start a neural network with JavaScript in 5 minutes”.


Robert Kasza works at XSolve since 2014 as FrontEnd Developer / JS Developer. He is programming practically in everything which is based on Javascript and related to this language, but his focus is on React and Angular. In spare time he loves to read about technical innovations and spends every free moment with his family.

white Land Rover
Business Featured Post

How BlaBlaCar beat the competition in the race for market domination in 27 countries.

When BlaBlaCar approached XSolve, they were at a stage of rapid growth with around 24 million users already buzzing about their excellent carpooling platform. But the visionaries at BlaBlaCar...

ebook holacracy practitioner guide
Business Featured Post

E-book: Holacracy Practitioner Guide

If you’re interested in this guide that means you are seriously thinking about introducing change in your organisation or possibly, you already have gone through a transformation. Congratulations, you are...

ebook cover
Business Featured Post

E-book: How to Create an Agile Office

We present to you an e-book which collects all our experiences and thoughts regarding creation of an agile office. Hands on, practical, functional. This resource was created primarily for...

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies.

To find out more click here

Ok, Thanks