Translator: Ten years on the trail

The original link

Over the past few years, websites have evolved into sophisticated web applications. Where once the Internet was all about simple business presentations, today, Facebook, Slack, Spotify and Netflix are changing the way you socialize and live. With the development of the Internet, the industry of front-end development has reached a new level and received unprecedented attention.

Like most front-end developers, our tech stack used to consist of HTML and jQuery. We use AJAX requests to fetch data from the back end, use JavaScript to render new UI elements and insert them into the DOM, and user interaction is achieved through event bindings and callback functions. Don’t get me wrong, I’m not against those approaches, and they still apply to most Web applications today.

However, when an application’s complexity dramatically increased, a pile of problems began to appear more frequently than expected: may your data updated, but missed to update a particular show, you through Ajax access and update the content, but no binding events, there are other problems, all these make out will be a long list. These problems make your code increasingly unmaintainable, especially on projects with multi-person teams. At this point, you need to use a front-end framework to solve the problems of collaborative development for you.

<! –more–>

1. The React the Gospel

When our team started looking for a suitable front-end framework, we considered many options and ended up with two — Angular and React.

Angular is by far the most mature solution: it has a large community, and you can find the right third-party modules for most application scenarios.

React is also competitive, its javascripts centric design looks promising, and it performs well. It’s still in Beta, but the fact that it was “developed by the Facebook team” gives it a competitive edge.

We decided to give React a chance and chose to use it.

React initially felt great, and we could do everything with JavaScript: Show a piece of HTML, render a list by going through a set of numbers, elegantly change the value of a variable, and then watch it propagate around through props, update the content to be updated into reusable components, and then you’re all set, no blobs of code, just really stop and think. React addresses our desire to write maintainable code in team development.

2. React + Flux = ♥

But going down the road, we found that not everything was rosy. The first big challenge we faced had us wondering if we should give up React — we were in a callback maze.

Because of React’s one-way data flow nature, if a child component needs to update its parent’s state, the parent component passes a callback function to it. At first glance this is no big deal, but if your component to update the root component of the state, you will have to “this. Props. UpdateCallback” a layer of a layer of passed down along the data flow.

Still, we like React and continue to use it to get our work done. Through our efforts, we found Flux, which is an architectural idea for standardizing one-way data flows. It consists of four main elements.

  • Store: Stores data and application status.
  • Action: Triggers the state change.
  • Dispatcher: Manages actions and directs them to corresponding stores.
  • View: Displays store data, dispatches action – this is already in React.

With Flux, we don’t have to store state in the root component and then pass update callbacks layer by layer to its children. The React component gets the data directly from the Store and changes the state by calling the action: it’s simple, elegant, and won’t drive you crazy. Flux adds predictable behavior and some criteria to code constrained by the React framework.

3. Angular goes wild…

… It uses HTML-centric code and is not super efficient.

Recently, I started working on an Angular project. By the time I joined, the project was largely complete, so Angular had to be used. There was no turning back. As a loyal React developer, I make fun of Angular. When I wrote the first line of Angular code, I cursed it. That’s what it’s called: If you love React, you hate Angular.

I can’t kid myself that at first I wasn’t happy writing Angular code. I feel uncomfortable writing the frame-defined properties (or, more properly, directives) into HTML. I had to struggle to implement simple features such as changing urls without reloading the Controller or rendering the base template.

When I encountered a problem in the form caused by the ngIf Directive creating a new subfield, I had a hard time dealing with it. And when I tried to remove some blank fields from a JSON file I was sending to the server, I noticed that the corresponding data in the UI was removed too — both ways binding. And when I tried to use ngShow and ngHide to show one HTML block and hide another, all of a sudden, both were shown. I understand that a lot of the problems are my own, and I want to point out that Angular is unpredictable and has all sorts of pitfalls when it comes to using it.

Of course, Angular is good at a lot of things. The built-in HTTP request module is great, and promise support is good. Another nice thing I can’t make fun of: the built-in form controller, which provides default formatting, parsing, and validation for input fields, and a nice plug-in for displaying error messages.

Angular also makes it easier for development teams to work with page production teams. On our team, we have dedicated page refactoring engineers who write HTML and CSS, and Angular makes it seamless: The refactoring engineer takes care of the HTML and some extra tags, and I take care of the logic. If we were using React, it would be a challenge to get the refactoring engineer to write components at least, either to learn how to write basic JSX, or I would have to copy and paste his HTML into JSX myself.

Remember the URL substitution and template rendering issues mentioned earlier? It doesn’t matter, people usually use third-party uI-Routers that are better than standard ngRoute. Finally, Angular isn’t as bad as I thought. Most of the previous complaints were either because I was used to thinking React or because I wasn’t professional enough.

4. Conclusion: AngularJS vs. ReactJS

React uses native JavaScript functions to allow developers to create reusable components that stream one-way data with a fixed lifecycle. React, combined with the Flux architecture (or other architectures inspired by Flux, such as Redux), makes it much easier for teams to maintain a project over time without worrying that fixing one bug will introduce more. However, if you have people writing HTML and CSS on your team, React imposes additional learning costs because it changes the traditional development process. And React’s effectiveness depends heavily on the modules you choose to make up your application.

Angular, on the other hand, focuses on simple two-way data binding, where when you change the contents of the Controller Scope, the changes are automatically synchronized to the UI (which works like magic). It thinks it saves configuration time, and developers don’t have to think about organizing their code in a variety of design patterns and selecting a core module from hundreds of alternatives, as traditional development models do. The use of bidirectional binding is convenient for development, but it is also prone to unexpected bugs caused by changes to parts of the code during long-term maintenance, especially code that has not been touched in the past few months.

So what’s my preferred way to build an app from scratch?

In the long run, I personally prefer React, using the Redux architecture, using Axios to support promise-ready HTTP requests, and using react-Router to handle routing. However, it depends on the experience of the team: if there were someone who wrote HTML and CSS, I would definitely choose Angular. Both frameworks have their pros and cons, but for the purpose of building maintainable projects, the most important thing is how to get people to write good code.