Comment by simonbarker87 | Hacker News Reader

Comment by simonbarker87 | Hacker News Reader

Parent Full thread

I think this is an important nitpick though in your defence. I have just started learning React having become pretty competent with Angular (day job plus some hybrid apps) and I have to say that I'm struggling to understand its popularity compared to Angular.

Angular feels fully fleshed out, adheres to MVC mostly and has nice separation of html, css and the UI TS code. I come from a native coding background so this feels logical and I can jump into a new project and get my bearings pretty quickly.

React on the other hand seems to be jQuery gone mad with CSS, JS and pseudo HTML all mixed together. Ternary statements in JSX is awful to look at.

To me it seems React is solely there to solve the V in MVC and then with a host of additional libraries (of the users choice) some kind of MVC system can be cobbled together if needs be.

I'm not saying React is bad, clearly it is very popular and has it's great use cases, but I don't think it's Angular vs React.

MVC is a popular pattern but it's not the only way to do UI. I don't personally care for it and I am happy that React doesn't force it on me.

As for mixing HTML, JS and CSS, I consider that a feature. Why do you want those separated? The reason for me to group code in a file, a folder or at a higher level, in a repository, is that I create a little mental context for what I am going to work on and I want the structure to enable that as much as possible. Now, when I am focusing on some feature it is much more likely that I will be switching back and forth between the HTML, CSS and JS of a component than switching between the CSS of one component to another.

It happens, of course, that I get into a mode where I want to edit many CSS files in one go for whatever reason, it's just much less common and thus I don't want to optimize for that case.

> Why do you want those separated?

You don't, there was a time when separation of concerns got mistranslated into separation of technologies and it became an almost religious mantra. But if HTML, CSS, and JS all combined to create a single black box component, that is a single concern, separating the technologies for separations sake only serves to reduce the reasonably of the black box. There are still those that where taught in that time, that separation of technologies and separation of concerns where the same thing, but they are not and that is well evident in that react component are easy to reason about.

To me, the killer feature of React is how easy it is to mix with standard "vanilla" JS libraries. The "React" version of a library is usually a fairly trivial wrapper around the "normal" version. In contrast, integrating with Angular is a lot more involved and is in effect its own ecosystem.

The other thing I can't stand about Angular is that it puts its proprietary templating language "in control" of components. Which means if you want to do something more complicated that isn't implemented in the templating language, then you just can't (or you end up fighting the framework). With React, it's as if the equivalent of Angular's controllers (components? - it's been a while since I used Angular) were in control. The templating is only for templating.

FWIW, I agree on the ternary operator issue. Although IMO this is actually a deficiency in JavaScript rather than in React/JSX: If if-else and switch in JavaScript were expressions then this problem would disappear completely.

Can you provide some examples? My experience is that almost any library you end up using is built specifically for React and not vanilla.

Compare https://github.com/nhagen/react-intercom/blob/master/src/ind...

with https://github.com/PatrickJS/angular-intercom/blob/master/an...

And that's the small one. There's also https://github.com/CaliStyle/ng-intercom

As another example, consider HTTP. Angular provides its own special HTTP class. With React I just use the standard Fetch API.

I have used react-sortablejs and react-leaflet in the past. I don't have any experience actually wrapping existing libraries myself though.

https://github.com/SortableJS/react-sortablejs

https://react-leaflet.js.org/

Redux can be used in projects unrelated to React.

Correct, React is essentially a tree diffing & reconciliation library tailored for the DOM. As such its foremost concern is to provide a declarative API for manipulating the UI tree.

How data flows into that tree is not its concern. This is why there's a wide variety of state management libraries available. Empirically I agree teams often get state management wrong, because it requires a different skillset than developing reusable UI components.

Frameworks like Angular make a lot of hard choices outside the view layer for you.

There's nothing wrong with ternary operators in my opinion - maybe it's just a subjective thing.

Most interesting thing in React for me is the ability to pass an element as an argument to another component - it's impossible in Angular. I’m not sure there is a lot of real-life cases for this feature, but still, I’m impressed by this level of flexibility.

React isn't just V of MVC, it's VC at least, letting you write your models wherever you want (pure js functions? classes - go ahead).

Some advantages of React are the weak points simultaneously - ngModel, ngIf, ngFor - they are removing a lot of boilerplate you have to write in React.

I don't see why the CSS is mixed with the rest. It clearly isn't. Mixing JS and HTML doesn't seem problematic to me.

Depends if you use CSS modules or the styled component library.

I've mixed plenty of html and js over the years and even html and php and it's nice to not have to anymore. Something about JSX rubs me the wrong way.

With React Native css is commonly mixed with the JS/TS, all in the component.

Reply on news.ycombinator.com