Ok, so I wrote a post about why I felt React was a bad library and another one about why I thought Angular was better and you guys had some thoughts. So rather than try and go through and respond to all of you individually, even though I’d really like to, I’m just going to try and respond to common themes in your responses.

For reference here are the other 2 posts I’m referring to (in order):

1. Why we need to stop using React
2. Why We Should Throw Out React and Pick Up Angular

You don’t have to read them if you don’t want to, but if you’re interested there they are.

Here are the top 5 most common responses/criticisms to my other posts:

1. Most of the React issues are just caused by bad developers writing bad code.
2. You don’t offer any solution or alternative.
3. This is all based on personal experience and I want to see more evidence.
4. I use React and my application is fine.
5. Angular is bloated, slow, stupid, etc., etc.

Before we hop right into it, I want to point out a 6th one that I’m going to try not to spend any time responding to. You know what I’m talking about, the people who just like to hear themselves talk. People who just call me stupid or say I’m wrong without offering anything constructive in return. If you think I’m wrong, I want to hear WHY. Don’t just be like “this sucks and I hate it”. If that’s your opinion fine, but at least have the courtesy to engage me in a discussion laying out your argument as to why that’s your opinion and give me something to respond to. I think that’s a fair ask.

If you’re just going to get all upset and feel the need to post something like “I hate medium because of articles like this” I’ll tell you what you can do. Go out and get a postage stamp, an envelope, and some paper to write on. Write your comment on the paper, fold it up nicely, carefully put it in the envelope, put the stamp in the top right-hand corner of the envelope, and then throw it in the garbage. I’m not attacking anyone personally with this so you can just calm right down.

Most of the React issues are just caused by bad developers writing bad code

This was probably the most common criticism I heard, and it’s a fair point. Since this is the most common thing I heard I’ll probably spend the most time on it as well. Yes, there exist bad developers who will write bad code. That is unavoidable and is not the fault of any programming language, framework, or library.

My original criticism is that React is something that allows you to essentially make a bunch of mistakes early on that will bite you later. I point to a lack of safeguards or standards in React itself as the primary cause of these issues NOT bad developers. The reason why is that when you make a React project, for better or worse you (or your team/company) are solely responsible for managing and maintaining absolutely everything from file structure, component structure, configs, etc.

Using a real-world example let’s say you’re tasked to build an application and you’re given a set of requirements. I think any developer currently in the workforce is familiar with this setup. So you build your React app for that set of requirements, you structure your component trees so they function perfectly for that set of requirements. Now let’s assume the requirements change, as they so often do. You now have an application completely optimized for a set of old requirements and now that you have something different you need to do you’ve backed yourself into a wall where you’re changing large amounts of code to try and accommodate the new requirements. Maybe you cut a few corners in the process as well as developers so often do (not judging at all, it happens to the best of us sometimes).

I want you to bear in mind that this is just a single example, but one of the more common ones I see uniquely on React projects. That could be because there are just more React projects out there than other projects, but the point remains. Now you can argue that “oh well that’s the developer’s fault again”. Is it though? Could they have planned their project a little better to be more robust, maybe, but I doubt it. The reason I doubt it is because of the component trees that I so often see in React because that’s literally the way React works. React forces you to build overly complex component trees, and now with the introduction of hooks in 16.8 that problem has become worse. Over time, no matter how hard you try, you’re going to have a far too complex web of nested components because React forces you to do it.

If you’re going to say, well my web of nested components makes sense to me, it very well might. However, you also have to acknowledge that the way that tree is structured is going to be 100% different from how any other React project has done it. This is because React does not enforce standards in the way components and applications are structured and created. This lack of standards is what leads developers to create a really specific solution to a really specific set of requirements, and that’s what leads developers to back themselves into a wall when things need to change. That’s when the refactoring starts, mistakes pile up, and things get messy.

My Preferred Solution

Let’s look at the latest version of Angular in comparison. The way Angular works is that everything, like modules, components, services, etc. are created with the Angular CLI. The CLI is going to create and scaffold your application and the pieces you create. This means that your components are always going to look the same no matter what when you talk about code structure. This already brings to the table a standard structure that will be the same across every Angular application.

Let’s also look at routing in Angular. When we talk about structuring the components and the DOM tree the Angular router has a lot to do with how the framework encourages you to structure your applications. In the project, you’re always going to have the main routing file in src/app/app-routing.module.ts.

https://gist.github.com/shadow1349/b534c727e3f032e09d58cc63026ed3c7

Let’s examine the landing route:

https://gist.github.com/shadow1349/424f997a6ff5173383152aec204ec4f8

What does this mean? This gives a clear and extremely readable standard for how routing works throughout the entire application. It’s also going to work the same way in every Angular application. From a project structure level, I can very easily find my way around the routes which brings me to the pages.

This encourages a very flat readable structure, which also lends itself well to being able to change more easily as well. So when those requirements inevitably change we have a flat readable structure that can change easily. Another great thing is that the only difference between a routed component and a normal component is the -routing.module.ts file. If you wanted to have, say a button component, you just wouldn’t include the routing flag when creating the module for it.

Let’s talk about modules as well. All of your components in Angular are going to have a module they are a part of. This helps you modularize your application. So basically, you can build your application in a modular way meaning you can easily and quickly arrange those modules in any way you see fit. This too solves the issue of backing yourself into a corner when the framework itself encourages modularization of your components as opposed to stacking them into a tree.

I really want to go on with this, but there’s more to get to and I don’t want to write a book about this right now.

You don’t offer any solutions or alternative

No, I didn’t, and that’s mainly because I didn’t want to write a whole book. Instead, a created a follow-up about why I think Angular works better. However, some criticisms were fair saying that everything has its place like React and Angular. So I’ll be really clear here. React has its place, but I think that its place is in small personal projects and possibly landing page websites. For all the reasons I’ve already talked about, I think large complex applications are better handled by Angular.

Now, that’s not to say that Vue, Svelte, or whatever else you use wouldn’t also work. The only issue is that I don’t really have any experience with either of those technologies so I don’t have enough information to make an informed opinion on it. I’d really like to try Svelte as I’ve heard it’s quite good (as many of you commented as well) and when I do I’ll certainly let you know what I think. I have a lot of experience with Angular and React and I can tell you how Angular solves a lot of the issues that I brought up with React, as I did in the previous section.

It’s all based on personal experience, I want to see more evidence

First off, yes of course it’s based on my personal experiences using React. That doesn’t mean that it’s invalid. I also think I’ve given a decent amount of concrete evidence to back my opinion. Take, for example, the section on the virtual DOM and incremental DOM. I had a link to an article that explains the inner workings of both better and also how the incremental DOM improves over the virtual DOM in efficiency and speed.

For those of you who wanted a more concrete example of how React’s no rules landscape leads developers into trouble, I went over that in more detail with specific examples in the first section so hopefully, that suffices.

I use React and my application is fine

I’ve never said you can’t have a React application that doesn’t function well. As I had mentioned, it has a place, but I think its place is very small. Some of you will disagree, and that’s fine. Just because you have an application that works well doesn’t mean that there aren’t larger issues with the React itself so let’s talk about them.

I want to start with updating versions. I mentioned this before and you guys had a lot to say about it. I mentioned hooks and you guys had a lot to say about that as well. Some of you mentioned that going from React 16–17 is completely non-breaking. That’s just not true and it has to do with the dependency hell you counter with React. Many of you tout the fact that React allows you to choose all your own tools as a positive thing. This is really a double-edged sword, especially for large complex applications. When you have something large and complex you’re going to need some tooling and you’re probably not going to have to write and maintain those tools yourself. So you go and start installing libraries and then you need another thing so you install another library. Maybe that’s fine, but it comes with some heavy consequences, almost as heavy as your node_modules folder is going to be.

One of the consequences is that few of these tools are maintained by the same person or group. Why is that important? When you have Angular you have @angualar/core and a bunch of other @angular dependencies. Now I don’t think anyone has ever actually typed out npm install @angular/forms or any other library that is part of the core library since it’s installed for you when you create your project. The great thing about the fact that these all come from the same vendor who also happens to be the vendor maintaining your framework is that the updates are always going to be smooth. Everything is always going to work together because the updates are always going to go across all the dependencies you use.

However, React is the complete opposite. Every time React makes an update, like hooks, you’re far more likely to be held up by a 3rd party library if you want to update. Hooks is a really breaking change. No, you don’t HAVE to upgrade right away but if you WANT to it’s going to be extremely painful if you have a large complex application. I would go so far as to say that the introduction of hooks into React version 16.8 was a really bad move since it changes the way that a React application can be written further muddying the waters of any semblance of standards. It changes the whole paradigm of how React works making everything functional. If you pay attention you will know that Facebook really wants everything to be functional and will retire class-based at some point. This will then force years old applications to upgrade which makes the whole development landscape with React unstable.

Some of you are going to compare this to Angular 1 and Angular 2. While it’s kind of fair, it’s also not. Angular 1 and Angular 2 are completely different things. They are totally separate libraries, whereas React is making this breaking change in a single library. You can (at the time of writing this) still write Angular 1 applications (I wouldn’t recommend it) even though the library has been sunset by Google. On the flip side eventually, you won’t be able to use class-based components in the latest versions of React. This is a little predictive, but I already see the writing on the wall for class-based React components.

There’s one particular comment I want to mention too which is someone saying that the Facebook website works fine on their phone and desktop so it can’t be that bad. To that, I have several comments:

1. Facebook still uses a lot of PHP for its main application. Since Facebook is a massive tech company they also have their own special version of PHP that is HEAVILY optimized and runs of GIANT servers which certainly increases performance.
2. Facebook is the creator of React so of course, their implementations are going to be much better than literally anyone else.
3. Facebook also has an army of incredibly smart developers working to integrate React into their main application. I can’t really speak for how it’s going internally because I don’t work at Facebook, but I can imagine having the team that created and maintains React on the payroll probably helps.

Just because Facebook’s website runs well doesn’t mean that React is great or that your application is going to work out the same. If you had the same resources and time as Facebook, maybe it would, but you don’t and you won’t.

Angular is bloated, slow, stupid, etc., etc.

I feel like this is a comment that is very stuck in the past. I mentioned on the Why We Should Throw Out React and Pick Up Angular post that Angular build sizes are actually really good nowadays. When you have a large application the build sizes of React and Angular are pretty comparable. Angular comes with tree-shaking right out of the box that will strip out any unused code/modules from your final bundle. Again that comes right out of the box, no work involved just like lazy-loading.

There is one difference though as I mentioned in that same article. The incremental DOM is by in large far more efficient in its use of host resources. That and the actual rendering engine of Angular itself is tree-shakable, unlike the virtual DOM. Some of you said that it doesn’t make that big of a performance difference. Well, actually it does. Remember the first section when I was talking about component trees? What do you think happens to those large component trees? They get put into the virtual DOM as a large DOM tree. Then on each re-render, another large chunk of host memory is being used to re-render and diff that whole entire DOM tree made up of your complex component tree. That will result in runtime performance costs that are noticeable and I have personally seen it happen many times. There are solutions to this, it isn’t an unsolvable problem, but it’s yet another roadblock in your development.

Let’s wrap this one up

Ok, so hopefully all of you commenting on my other post can read this and hopefully this gives more clarity into the arguments I’m making. As I said at the start I’m always happy to engage in a discussion, but that starts with you giving me something constructive not just “this is stupid blah blah blah”. Looking forward to hearing from you!

If you’ve enjoyed this article I’d love for you to join my mailing list where I send out additional tips & tricks!

If you found this article helpful, interesting, or entertaining buy me a coffee to help me continue to put out content!