Nitpick, but React is not a framework, it's a library. People miss this point often eg when they compare React 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.
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.
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.
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.
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.
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.
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'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.
Let's say that if I want my own version of select2, I can develop it with react, though not easy.
Providing convenient mechanisms for managing high-level/application state moves them squarely into the framework category, imo.
But, as others have pointed out in this thread, a much more useful distinction is where the library's code gets called in the stack. If your code is at the top of the call stack with library code below it, then it's a framework. If their code is at the top, then it's a library. In short, you call a library, a framework calls you (inversion of control). So in that sense React is most definitely a framework.
Also, I'm willing to be wrong on this one if somebody can give me a meaningful and objective reason that React should be considered a library but Angular should be considered a framework.
- You hand it your code and it calls your code when it wants to
- Your code must conform to React's expectations.
React is _not_ a framework, because:
- It only focuses on one thing: defining a tree of UI components. It doesn't include anything for HTTP requests, module definitions, generating expected file structures, or any of the other stuff you'd see in Angular and Ember.
- You are responsible for initializing React in your app, and you can use it in a range of situations, from a full-bore SPA to adding some interactive widgets to an existing page.
All those are true simultaneously.
A framework calls your code.
Really great explanation here: https://stackoverflow.com/posts/15600924/revisions
Edit: another really nice exposé here: The Difference Between a Framework and a Library — https://www.freecodecamp.org/news/the-difference-between-a-f...
A project is added to a framework.
So how is React a library? You can't just utilize part of React within an existing Angular app. I've built shims between the two frameworks and you can't just use React inside of Angular. When you utilize a React component inside of Angular, everything Angular about the application goes out the window and it becomes a mini React app starting from that component, just with the data originating from an Angular app.
The definition of a framework boils down to inversion of control, right? You define your application, and then it is run within the React "framework" context, which calls various predefined methods/functions.
All of the lifecycle methods in React are a good indicator, to me, that it is indeed a framework. You define these functions, and they are called by the framework. Inversion of control.
react-router, redux etc. are all different libraries. Point still stands: You have to pick and assemble these different parts yourself. And then still all those libraries don't call into your code, but your code includes and wires them up.
Though I don't know if it still can be considered as framework or not.
It's a framework which advertises itself as a library.
In reality, there is nothing library-like about bypassing the DOM for rendering and making developers use a custom programming language (JSX)... and please don't give me this tired old argument that JSX is not compulsory! Has anyone ever seen a real React application which does not use JSX? Exactly.
If 99.9999% of developers are using React as a framework, then for all general communication purposes, React is a framework.
I've built one without using JSX and I think it's superior. The problem is the tooling and type support just isn't there so going against the grain here is pretty much asking to be burnt.