I'm glad you asked , LOL. I worked as a professional React dev for about 9 months ( part time ) and I've been a professional Angular dev for over a year.
I hate React, and JSX the primary reason. CSS in JS is another ( not required for React, but prominent ). First, however let's talk about JSX.
Separation of concerns was the ENTIRE reason we decided to put controllers, HTML, and CSS into different files. JSX muddies the waters so much that there are some JSX novels that I've seen and worked with that read very much like a horror story.
Heiker's example is a good example of this. What I love about Angular is that your component's html file is, well, an HTML file. Sure, it uses structural directives and some minimal ( very readable ) interpolation, but it's nothing compared to the spaghetti mess the JSX usually becomes.
When it comes to very complex views, nothing is worse than having to mentally map your way through a React component with endless JSX acrobatics that you have to translate into your mind into a coherent web page. For simple views, it's fine. But in some of the more complex views that I've seen, it's just ridiculous.
There's a reason why Angular tends to be the framework of choice with much larger and robust enterprise applications. It scales better, and it's easier to deconstruct and refactor the architecture as things grow and change. To me, React is beautiful , fast , and elegant for smaller and medium sized projects, but once the projects scale, it can become a Frankenstein very quickly. There's no real universally agreed upon pattern for how React should scale. ( Not to my knowledge ) , where Angular's structure is baked into the framework.
I didn't bring up TypeScript because technically you can use TypeScript with React, but TypeScript being in ALL Angular projects is the other major reason that I love it.
The only thing Angular has going for it IMO is that it's very opinionated in how you structure literally everything. That's fine, but it's very limiting, and sometimes you end up fighting the framework to do what you really want.
As for React, it's far less opinionated. In fact, it's not even a framework--it's just a library, so I don't really think the two are comparable.
As for the JSX soup problem, I think you can really chalk it up to a clash of paradigms and a lack of discipline.
React components should be very small, and only concern themselves with rendering the view on the page. That includes layout, data, and minimal logic (e.g. mapping a function over list items) required to render the correct view.
All of the business logic and technical bits like state management should live inside a higher-order function that wraps the component. The Angular equivalent of this is to have a "dumb component" with a service class to manage the business logic.
That's just a design pattern that people need to recognize and use, just like we have design patterns in Angular. It's just that React doesn't generate boilerplate code to enforce design patterns like Angular's CLI does. To me, that's a good thing, and I'm not alone in that belief. But it does open up more opportunities for programmers to do idiotic things.
So it sounds like the debate is really about a clash between the more traditional OOP paradigm (angular), compared to a library based heavily on functional programming concepts (react)
I suppose you could make the argument that JSX is the end result of committing to a functional programming paradigm as it would relate to view interpolation. I understand that argument ( kind of ), but Angular's method of view interpolation could have been designed to fit within a functional programming paradigm .
In other words, my biggest gripe about React is JSX itself and functional programming does not require you to assemble Frankenstein entities like JSX any more than Angular's view interpolation is inherently OOP. In Angular, having things like ngModels and 2-way data binding make it classical OOP, but those things are not what I'm enamored with. I'm enamored with "separation of concerns" between the view, CSS, and the component. React cannot give me that. Angular can and does. That's why I went back to Angular after doing React for almost a year.
To the other point @austin
made about JSX elements being ideally very "small" and modular, I get that too. But what I found myself doing with React was digging through 10 different components whose JSX all hooked into each other. Having to mentally map all of this when exploring more complex widgets and it can get VERY unwieldy. There's a reason why we separate components from views and I just don't like those two things being combined in React.
However, to each their own, and React is very popular so I'm not knocking it at all. If I have to use it again for an important project, I will.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm glad you asked , LOL. I worked as a professional React dev for about 9 months ( part time ) and I've been a professional Angular dev for over a year.
I hate React, and JSX the primary reason. CSS in JS is another ( not required for React, but prominent ). First, however let's talk about JSX.
Separation of concerns was the ENTIRE reason we decided to put controllers, HTML, and CSS into different files. JSX muddies the waters so much that there are some JSX novels that I've seen and worked with that read very much like a horror story.
Heiker's example is a good example of this. What I love about Angular is that your component's html file is, well, an HTML file. Sure, it uses structural directives and some minimal ( very readable ) interpolation, but it's nothing compared to the spaghetti mess the JSX usually becomes.
When it comes to very complex views, nothing is worse than having to mentally map your way through a React component with endless JSX acrobatics that you have to translate into your mind into a coherent web page. For simple views, it's fine. But in some of the more complex views that I've seen, it's just ridiculous.
There's a reason why Angular tends to be the framework of choice with much larger and robust enterprise applications. It scales better, and it's easier to deconstruct and refactor the architecture as things grow and change. To me, React is beautiful , fast , and elegant for smaller and medium sized projects, but once the projects scale, it can become a Frankenstein very quickly. There's no real universally agreed upon pattern for how React should scale. ( Not to my knowledge ) , where Angular's structure is baked into the framework.
I didn't bring up TypeScript because technically you can use TypeScript with React, but TypeScript being in ALL Angular projects is the other major reason that I love it.
The only thing Angular has going for it IMO is that it's very opinionated in how you structure literally everything. That's fine, but it's very limiting, and sometimes you end up fighting the framework to do what you really want.
As for React, it's far less opinionated. In fact, it's not even a framework--it's just a library, so I don't really think the two are comparable.
As for the JSX soup problem, I think you can really chalk it up to a clash of paradigms and a lack of discipline.
React components should be very small, and only concern themselves with rendering the view on the page. That includes layout, data, and minimal logic (e.g. mapping a function over list items) required to render the correct view.
All of the business logic and technical bits like state management should live inside a higher-order function that wraps the component. The Angular equivalent of this is to have a "dumb component" with a service class to manage the business logic.
That's just a design pattern that people need to recognize and use, just like we have design patterns in Angular. It's just that React doesn't generate boilerplate code to enforce design patterns like Angular's CLI does. To me, that's a good thing, and I'm not alone in that belief. But it does open up more opportunities for programmers to do idiotic things.
So it sounds like the debate is really about a clash between the more traditional OOP paradigm (angular), compared to a library based heavily on functional programming concepts (react)
@jordan Lee , well yes and no.
I suppose you could make the argument that JSX is the end result of committing to a functional programming paradigm as it would relate to view interpolation. I understand that argument ( kind of ), but Angular's method of view interpolation could have been designed to fit within a functional programming paradigm .
In other words, my biggest gripe about React is JSX itself and functional programming does not require you to assemble Frankenstein entities like JSX any more than Angular's view interpolation is inherently OOP. In Angular, having things like ngModels and 2-way data binding make it classical OOP, but those things are not what I'm enamored with. I'm enamored with "separation of concerns" between the view, CSS, and the component. React cannot give me that. Angular can and does. That's why I went back to Angular after doing React for almost a year.
To the other point @austin made about JSX elements being ideally very "small" and modular, I get that too. But what I found myself doing with React was digging through 10 different components whose JSX all hooked into each other. Having to mentally map all of this when exploring more complex widgets and it can get VERY unwieldy. There's a reason why we separate components from views and I just don't like those two things being combined in React.
However, to each their own, and React is very popular so I'm not knocking it at all. If I have to use it again for an important project, I will.