Don’t blame the Framework: Experience when working with Angular and React


Over the past few years, websites have grown into more sophisticated web applications, and previously simple business information sites, have now been replaced by Facebook, Slack, Spotify and Netflix. They changed the way you communicate, listen to music, or watch movies. The development of Front-end has reached a new level and now it requires more attention than before.

Like many other front-end developers, our stack includes HTML and jQuery. We perform AJAX requests to the backend, render UI on javascript and insert it into the DOM. User actions will be monitored by binding events and callback to each element. And this is applicable on most applications.

However, when an application grows rapidly, a few starting issues occur more frequently than originally expected: you forget to update all the locations where a value is displayed in the UI, no What events are linked to the content added by AJAX, … This is a sign that your codes are not maintainable, especially when developing with a team. Using a front-end framework provides a formal way to write coordinated codes that you can easily read, write and update.

1. The beginning of React

When our team first saw the need to apply a front-end framework, we came up with a number of options to consider: Angular and React

Angular is considered the most mature candidate: Angular has a strong community, you can learn common situations and how to use from 3rd party modules.

React has made its first big steps, React’s Javascript-centric code works fast, promising. Although still in beta, but assigned the “developed by Facebook” label, React was much more trusted. And we decided to choose React.

At first, it was really satisfying to do everything using Javascript: display an HTML paragraph or not, render a list by iterating through an array. React also did a good job of changing a variable’s value and saw it spread to all parts of the codes via props (one of the component attributes of React), breaking things up into reusable components . React has brought the necessary consistency to develop codes that are maintainable.

2. React + Flux = ♥

But when applied to reality, everything is not like pink. The first big challenge we encountered and really made us think, is whether React is worth using – or the labyrinth of callbacks.

Due to React’s one-way data flow, a component needs to receive a callback to enable state changes on the parent component. This doesn’t seem to be a big problem until you realize that the component is going down, now you need to update the status of the root component. You must go through all the files and pass "this.props.updateCallback" down to stream line.

However, we still like React and are still working on it. One paid effort: We met Flux , an architecture to implement and formalize unidirectional data flow. It consists of 4 main components:

  • Store : Where data (application status) is stored
  • Action : Activate a state change
  • Dispatcher : manages and navigates actions to the right place
  • View : Displays data in the store and sends actions

With Flux, we do not need to keep the status on the root component, and pass the callback updates to their children. React components will take data from the storage directly and change the state by calling actions: it’s simple, elegant. Flux adds a predictable behavior and several standards to improve React code flexibility.

3. A rebellious Angular appears ….

…. Angular uses centralized HTML code and it doesn’t seem to be maximizing

Recently, I started working on an Angular project. Most of the project has been completed, so I have to finish the rest. As a developer who is loyal to React, I have some complaints about Angular. I even cursed it – even if it’s the first codes Angular I’m writing professionally. After all, I noticed: if you fell in love with React, you would hate Angular.

And I can’t deceive myself, in the first time, I don’t like working with Angular code at all. Embedding all specific properties (directives) into HTML code doesn’t seem to be fine. I have struggled to complete simple tasks, such as changing the URL without reloading the controller or creating a simple template.

The difficulty continues when I encounter a problem in my form, because ngIf directive creates a new sub scope for it. Or when I want to delete empty fields from a JSON sent from the server and it also deletes that data from the UI – oh, that’s two-way data binding. Or when I want to use ngShow , ngHide to display HTML block or hide other components, in about 1/100 seconds, are both displayed simultaneously ?? I understand most of these problems are my fault – I want to point out that Angular is unpredictable, it is full of surprises.

But of course, there are many things that have been made easy with Angular. Angular’s HTTP request module is really good, as well as support for Promise. Another thing I can’t complain about is: the built-in form controller. Input fields have a default mechanism for formatting, analyzing and validating, as well as a good plugin to display error messages.

By using Angular, you will find it easier to work with a team design. In our team, there is an engineer who writes HTML and CSS, and Angular lets us work together really seamlessly: he will be in charge of HTML and some extra tags, while I will take care logic processing. If we use React, at least he will have difficulty writing components, because he has to learn the basics of JSX (or I have to copy and paste his own work)

Remember the replacement URL and render teamplate I mentioned earlier? Never mind, I found that most people use a different routing library (ui-router), which works better than the standard library (ngRoute). And finally, Angular is not as bad as I thought. Most of the things I complained about earlier were because I forced the way React worked on Angular code or because I didn’t have enough experience.

4. The bottom line: Angular and React

React uses native Javascript functions to allow developers to create reusable components with predictable life cycles and one-way data streams. Combined with the Flux architecture (or one of its variants – Redux), it will become more reliable, making it easier for a team to work together for long. But if you get someone who only specializes in HTML and CSS, it will cost you a certain amount because it changes the traditional development flow. This depends on the module you choose to compose the stack.

On the other hand, Angular focuses on simplicity in two-way data binding design – what you change within the controller’s scope will be shown on the UI. The stubborn nature of Angular saves setup time by setting a number of patterns in how the code is organized, then selecting the core module from hundreds of other options is no longer necessary. However, similar to two-way data binding, although programming is simpler, it is also easy to make a surprise when changing some parts of the code in the long term – especially if the code is something that colleagues Your writing has not been touched in the past few months.

So after all, which framework should I choose to build an application from the beginning?

In the long term, I personally choose React, use Redux architecture, Axios for HTTP requests and react-routers. But this choice still depends on the experience of the team: if someone specializes in writing HTML and CSS, I will definitely choose Angular. Both frameworks have advantages and disadvantages, the most important thing to maintain a project is the commitment of developers to write and manage good code.


Share This:

Comments are closed.

Powered by FrontNet