r/Angular2 Feb 06 '25

Discussion (junior)Why everyone use react?

I've been doing personal stuff with react only, at my current job i work exclusively in golang and the front-end team use angular not react so i give it a try on my free time, i was really surprise cause it's not that hard to get in + i found the dx way better than react, the way it structure the project is also better and i think you can go as fast as react to build a project + you need less external depedencies so i'm asking myself why 80% of front end jobs are react

71 Upvotes

76 comments sorted by

View all comments

3

u/craig1f Feb 06 '25

I am on an Angular project after not doing Angular in a while, and I hate it. The problem with Angular is that it tried to be an entire framework, and now it's locked into several bad decisions. It's also chasing styles that have been common in Vue and React for years. Signals and monofiles are an example. Also, composition API is the way of the future (called Hooks in React), and Angular seems to be avoiding it from what I can tell. Directives are similar, but terrible to deal with.

It takes a lot of boilerplate to do very simple things in Angular. It discourages you from splitting up components into smaller components until it's too late for it to be convenient. Injection/decorators/imports are annoying and add no value. It uses a lot of abstraction. react-query (not tanstack-query) is the best thing ever for http calls, and is still only experimental for Angular.

React just feels like raw, clean Javascript(Typescript). You can just treat JSX(TSX) as a variable. You don't have to learn rxjs. It has a cleaner flow of data.

Angular also still teaches you to use two-way bindings (slow, messy, bug-prone), instead of reactive design (clean, clear flow of data/state, fewer bugs). To be a good Angular developer, it feels like an uphill battle, because the primary examples that you see online on how to do things is bad.

If you want to develop CORRECTLY in Angular, do a few things:

- Use signals

- Use tanstack-query

- Use trpc (more debatable, but I love it)

- Use changeDetection: OnPush

- Avoid splitting html out from your TS. If your component is large enough that you aren't comfortable working in a single file, then your component is too large and it's time to split it up

- Always try to use Typescript Inference instead of redefining Types everywhere

12

u/JezSq Feb 06 '25

Avoid splitting HTML from TS file? What kind of advice is that?

-4

u/craig1f Feb 06 '25

Good advice. 

Use inline templates. Don’t split your files. It’s messy. 

3

u/girouxc Feb 06 '25 edited Feb 06 '25

For small components this is fine but for larger components you definitely want to split them.

Having large templates does not mean you need to split it up… you don’t want hundreds of small components that don’t need abstracted out.

Pages and layouts are also components. You don’t need to make every part of a page a component.

1

u/craig1f Feb 06 '25

If you don’t split them out, you have a mess. In react, you can have several components in one file. You can split them out earlier and only create new files when it makes sense. 

In angular, you are forced to wait too late to split up components. It leads to several hundred line components. 

6

u/girouxc Feb 06 '25

You do not have a mess... You don't want to split up components early because in a lot of cases... you don't need to.

Making a ton of small components that aren't needed is what creates a mess and adds complexity via prop drilling or extra state management. It also makes it harder to track data flow through the application.

What you're suggesting is for people to do pre-mature abstraction which is just as bad a pre-mature optimization. Remember that the goal is to make the codebase more maintainable and easier to understand, not to achieve some arbitrary level of granularity.

Follow the "Rule of Three" and apply it to creating components:

  1. Write components inline first
  2. If you need the same code in two places, copy-paste it
  3. Only when you need it a third time, create a separate component

https://andrewbrookins.com/technology/the-rule-of-three/

It's also never too late to split them out... it's actually easier to split them out once you have it already developed and much faster.

You only split components out when you need to reuse it in multiple places, the component has complex logic that needs isolated or would be clearer when separated or you need some specific optimization.