Why is it React and not Angular?

ASP.NET with C#. Then it was not called Web Forms yet.

Web technologies have changed, each time revolutionizing my brain: ASP.NET MVC, JQUERY, AngularJS. And it was the last one that made the most significant impact, because only then did I find out that it is possible to build a web application without server views (aspx, cshtml). Plus, I learned about Node JS (“What? JavaScript on the server? I don’t believe it!”). And then I made a decision that I would not have believed before: to leave C #, which I had been “dedicated” for 9 years, and completely immerse myself in JavaScript.

I really enjoyed writing on the new web framework from Google. Very quickly things came up that I had to work hard with jQuery before. SPA was already a standard, below which, it seemed, it was a shame for a web developer to fall.

Writing in angularjs was a pleasure. There was no cli, but it was possible to create and configure a new working project from 0 in 20 minutes. On pure es5, without babel, traceur, wepback (the latter did not seem to exist yet). Then there were already rumors about the imminent appearance of angular 2 and its absolute incompatibility with the first version. Google put developers in a difficult position: on the one hand, their hands itched to rewrite systems with ASP.NET to a cool new framework. On the other hand, the question is: are we going to rewrite it now, and then rewrite it again?

Personally, when I saw code examples in angular 2, I really hoped that this would not take off. I wondered why they made it so difficult. And with each meetup dedicated to the new version, which I had to visit, the desire to switch to the second version was less and less.

And with the release candidate, it was decided to start creating a new project (and in fact rewriting the old one a little differently) already using angular 2. I’m not even talking about the fact that with the update of these release candidates, I had to rewrite large sections of code. Angular 2 was so uncomfortable to write that I felt pain when I rewrote the code. Raised the question of whether it is worth doing this or can continue to write in angular 1. But despite the fact that so far there have been many problems and incomprehensible bugs (I remember that the description of the error in the console was very detailed … That’s just absolutely not about where the error actually was), a bunch of incomprehensible functionality (I remember it took a lot of time until we understood what forChild was in the module description), everyone understood that it was impossible to stay on the first version, it was necessary to move forward. That is, the transition to a new framework was no longer because we wanted to, but because Google forced us, there was no choice. Then the thought flashed through my head that it would be better to actually switch to React. But I pushed this thought away, because I felt that I needed to follow Google).

Over time, of course, I got used to it. Got used to the idea that Observable is the new Promise. The code tried to write in such a way that they were everywhere, as much as possible async in the template. And a large number of operators in the chain (this is even before pipe) made me think that the code looked very cool.

Over time, I looked at this code and imagined in my head how it would look like with Promise and realized that this way the code would be much clearer and more readable. But I assured myself that Promise was junk and followed the trends.

And the trends were such that it suddenly turned out that the code needed to be written using ngrx and, in general, all components should be done onPush. I’ve looked at the example of a todo list via ngrx several times with a bewilderment: “WHY??”. After all, it was so easy and convenient. I understood that there was nothing left of the very angularjs in which I started writing, not because it was necessary, but because I just fell in love with it.

The widespread use of rxjs where it is necessary and where it is not necessary. Over time, I no longer observed any data objects or functional logic in the code. A set of operators like: mergeMap, switchMap, mergeAll, switchAll, combineLatest, combineLatestAll… well, you understand me. It seems to me that everyone else who wrote this code did not themselves understand what was happening there, but continued to erect these “compositions” on the pedestal of the ideal code standard.

What about http requests? Well, why, if I want to fetch data and call the getData function, do I have to subscribe? Subscribe to what? It’s not websockets. Addressed to the server – brought the data. And I’m not even talking about how many times it happened that you call a function, but the data does not come. And you think, guess what’s the matter? And the point is in the absence of subscribe. getData now returns an Observable. Well, in general, in a new way, now you write like this

this.data$ = getData()

And then in the template itself

{{data$ | async}}

And yes, it does work! And then you scratch your head and think: how now to bring the second page? Or just update the data? Call getData again? So why? It does not launch a request, but returns an Observable, and we already have it in our hands. It doesn’t seem to work anymore. So subscribe is needed? And here many more are trying to unsubscribe the request in onDestroy. Apparently they do not understand that the observable “ends” after the request. But as a supporter of http requests to observables assured me, that when a user, for example, went to a page and the request got stuck, he can press back (oh how) and the request … stops! Well, yes, this is of course a justified scenario for using observable instead of promise (which, by the way, can also be abort for a minute)

I felt like Google had cheated me. Cunningly and step by step, they replaced what I once liked with something else that they considered right. But I continued to write in angular, because I believed in this way, driving away “sinful thoughts”.

And then my team leader, having moved to a new company, offered to join him a few months later. There were 3 arguments (not counting the slight increase in salary, which they already offered me, at the current place, so that I would stay): closer to home (about minus an hour a day on the road), finally get nodejs on the back (we had attempts type it in but didn’t find a good reason to do so) and… Try React. I thought, consulted with people who tried both and everyone definitely preferred react, compared the popularity of frameworks (npmtrends, popular sites on react / angular). And he decided to take a responsible step in his life: he rushed headlong into the world of the new.

And then I realized what I was missing so much in the new angular: simplicity. Everything is elegant and easy. The code looked more like JavaScript than in the case of angular. I felt more freedom, the ability to choose different libraries, styling components, choosing state management, in the end.

Yes, at first it was not customary to write html inside JavaScript, until I realized that it was no longer html, but JSX. It was also inconvenient that now, when I, for example, built a tree component, I could not collapse / expand the node as before:

node.expanded = !node.expanded

But in some ways this is more correct when it comes not to a quick example, but to ready-made functionality.

Now I’m writing react projects. Thanks to functional components and hooks, the code looks very minimalistic and as readable as possible. At the same time, sometimes you have to return to old projects written in Angular. And the code is written as unreadable as possible (but it already depends on the crookedness of those who wrote this code before I joined the company. It’s just that in my opinion, modern practices of angular made it possible for the “crooked” to write everything in this way). Trying to understand this code and add functionality to it gives me pain.

To summarize why not Angular in my opinion:

  1. Google did one thing at first that caught the attention and hearts of web programmers. And then they gave something completely different, using the name and reputation of the beloved platform

  2. Widespread use of rxjs where it does not fit at all

  3. With each version talk about performance improvements. But apparently this is achieved by the fact that the default is now OnPush (oh, where is my 2 way data-binding from 2014)

  4. The feeling that a huge colossus is being loaded into the browser

  5. As a UI library, they push Material with elements to half the screen (I like material design on android, but not on the web). For that, you know, everything you need for development is on one site and you don’t have to go anywhere else, everything is there, on angular.io.

  6. After Google killed AngularJS (and not only him) they can hardly guarantee the eternal life of Angular.

  7. There is no freedom of choice. Google seems to be saying: we ourselves know what you need and how you feel better. Although many (fans of angular) represent the absence of this freedom as the absence of the “Wild West”. As if keeping the programmer within the framework will align his hands

  8. And of course, in this case, I was influenced by the incredible jump in the popularity of react. Although this factor is rather additional. Otherwise I would use redux

In general, I have many colleagues who love angular, ngrx, consider this path the only and not repeatable and the best, and they do not agree with my opinion. So choose what you like, what is convenient. The main thing is not to forget that most likely someone else will read your code and maybe you don’t want to hiccup at this moment 😉

Similar Posts

Leave a Reply