Originally posted on my personal blog
Iβve been building webapps with Angular 2+ and Ember.js since 2016 but I never got the chance to start a React project before.
I once did some changes in an existing react app when I was working at CrazyEgg but they were mostly CSS. I really never had the full experience. I never dug deep into React.
So I decided to do so and I allocated 40 hours to build a simple React CRUD app and dig my way into the source code and to learn how it really works throughout the journey.
I use Toggl to log my time. Awesome tool.
React is aΒ library
Angular is not.
Angular is an opinionated MVC/MVVM (or MVW) framework that comes with several smaller packages (or libraries) that handle a wide array of functionalities like routing, http requests, animations, forms,β¦etc.
On the other hand, react is just a V. It's really only concerned with the View layer. Woah woah hold on! Don't get me wrong, I'm not trying to put down React. Actually that kind of specialization gave React a couple of advantages and it definitely beat Angular in some areas that are discussed in the rest of this post.
One could say that React gives you much more freedom. Less boilerplate and faster initial setup. But however if you are going to build a complex webapp using react you need to rely on other libraries like react-router, react-promise, or Redux. Maybe Enzyme for testing.
It's common in React that you may rely on state management libraries like Redux or MobX.
Of course we still rely on external libraries in Angularverse like RxJS or NgRx for state management.
One Angular disadvantage that it has a much steep learning curve. Angular architecture is kinda influenced by backend Java frameworks. It is built using TypeScript (a must actually) and it has a clear-ish standard file structure. If you come from backend background, that would be great. Otherwise, you have to understand what is dependency injection and what are static types, add to that some basic OOP concepts like inheritance and polymorphism.
React's architectureΒ ? It doesn't haveΒ any.
There are some best practices though.
Which can be great if you want to do a simple SPA or crazy animation magic without worrying about the project structure hassle. But it also means a whole lot more decision making if you wanna build a full-fledged app, an analytics dashboard for example. These decisions mostly include picking third-party libraries, choosing how to go about code organization and file structure, sticking with JS or using TypeScript (yes you can TS in react).
Markup
"Let's have everything in one place"β-βA wild Facebook Engineer, 2013
React introduced JSX and everyone went crazy. It was controversial for brief 2 years then the frontend community realized it's actually not that bad.
In JSX you have JS logic inside your HTMLΒ β¦or maybe you actually write HTML inside JSΒ .. wut?! π€π€π€
// Something like this
const element = <h1>Hello, world!</h1>;
// or even this
const element = (
<h1>
Hello, {formatName(user)}!
</h1>
);
// Look at this
const greetings = ['hola', 'Hello', 'Hey', 'sup'];
const listElement = (
<ul>
{greetings.map(
greeting => <li>greeting</li> // π€―π€―π€―
)}
</ul>)
On the other hand the conservative Angular has a clear separation of UI and logic. You write your template in the HTML file in TypeScript in theΒ .ts file like how our parents raised us.
This distinction is highly debatable. While the Angular way is more readable and easy to understand if you come from any formal framework-y experience. JSX has better code completion and compile-time checks as everything is one file. Keep in mind, you also have to learn how to use custom directives like ng-for and ng-if to make use of Angular special "HTML on steroids" version.
Data binding
Whether you have a separated template file and TS file or you have them mixed up in a JSX file, at the end of the day you have a UI and some logic that runs it. Say you have an input field in the template and it pulls its value from a JS variable.
Angular MVVM data binding.
In Angular this value can flow in both directions, if you change it programmatically in your TS code or if you changed in your browser writing in the input field. This is called two-way data binding.
React works a little bit differently. You can only change this state (value of the JS variable) programmatically, and then the UI gets updated automatically. But if user changed the HTML input field value from the browser, that doesn't reflect on the JS variable. This is one-way binding. To achieve two-way binding in React we rely on callbacks and DOM events.
// Updating state in React
<input value={someData} onChange={({ target: { value }}) => this.setState({ someData: value })} />
DOM Manipulation
If you know what you are doing, React is fast. Really fast.
The reason behind this is that React uses a Virtual DOM which basically diffs the DOM tree looking for changes and then only updates the changes (like how git works).
Angular uses Regular DOM that traverses the whole tree till it finds the target element it wants to change and then edit it.
In the grand scheme of things this difference in performance is negligible unless you are doing crazy stuff with lots of elements in the page (Say more than 1500). This can actually block the main thread of the JS engine and freeze the UI if you are not careful.
Unit Testing
Using Angular CLI you can set up your project to include the boilerplate file provided by Jasmine testing framework which runs by Karma test runner. You can also use Karma to replace Jasmine with other frameworks like Mocha or QUnit. Karma plays very well too if you want to integrate with continuous integration services like Jenkins, TravisCI, or CircleCI.
React uses Jest out of the box with no need to do any configuration. You can also use AirBnb's Enzyme library next to Jest. Enzyme mimics JQuery API to facilitate DOM interactions in tests.
That's all folks!
Oldest comments (12)
That's some note worthy reading.
it's true. Dependency injection just introduces unnecessary complexity. It's killing angular.
By the way, I would also suggest you take a look at VueJS. It's nicely designed focused on developler simplicity.
Dependency injection is a good thing. With it you can decouple the creation of a dependency from its usage. It comes very handy at unit testing also.
Agreed. It's just unusual for frontend developers. As Hatem said, backend background helps in understanding this amazing tool. It's pretty complex but is able to improve your app's modular achitecture drastically.
For instance I've used it to create a web analytics reporter. Its logic had to be different depending on from what URL user opened it. So I created an abstract class and injected it to components and services. When the app started, a factory function detected which implementation to use. That's it. Very clear architecture.
I mainly work on the back end. I understand DI has become a defacto standard in statically typed languages. However, I suffered from DI framework deeply after intensively writing and reviewing Spring or Guice based applications for many years. I saw how productivity gets impacted by overusing DI in many organizations. I'm not against DI pattern, but against the DI framework that brings complexity, magics, ceremonies, and bad practices. I even come out with an alternative solution regarding decoupling, customization, and testing. I call it Injectable Factory. You can take a look if you're interested.
Funny. If I had to point to one major failing of Angular, I'd say it's the structural directive syntax, which leads to
ngIfandngForbeing much less ergonomic than the vuejs equivalents. The whole concept of a structural directive, with*being syntax suger around<ng-template>is confusing. I find this to be a big deal, because structural directives are very common / a fundamental building block of the framework. In general, I think structural directives incorrectly push too much logic into the view template (logic which would be better handled in javascript).Conversely, I find dependency injection to be the single best feature of Angular. But this is why multiple frameworks exist: so some people can choose Vuejs or React, and others can choose Angular.
Yes I totally agree. I was writing the part about UI and logic seperation with a grain of salt because we still *ngIf and *ngFor in the template.
But yeah at the end of the day if your project doesn't have any extra special requirments, any framework will do. And it becomes a matter of which framework your engineers are comfortable with.
Thank you for writing this article, Hatem. I've always wondered what an experienced Angular developer thinks of React, because ...well, I also switched between these technologies - not once, but twice actually. My first contact was with React. I tried to introduce it in a RoR project using Coffeescript instead of JS. I've read that React was a library only, so I was pretty sure it was possible to integrate it in the V of my RoR project. But using Coffeescript in JSX files (being CSX?) did not work out well. The result was so-so. I was glad to abandon this patchy tech stack recently.
Some years after this React encounter I suddenly had to learn a bit of Angular 2.x in one of my projects. Though I was overwhelmed by JS I somehow felt Angular being a nice and complete framework. The same feeling I had many years ago, when I learned RoR. So with Angular I somehow felt "home". Sure, the learning curve was steep, especially all the ES2015/2016/... stuff, but in Angular I could just follow the documentation in order to know where to go.
Then I switched again to a real React project (with a new backend). Suddenly I felt lost. Even though I knew why e.g. react-router and axios were not part of React, I could not appreciate this freedom. Instead I wished I had a complete framework that gives me the complete technology stack for the frontend.
Yes, a library gives you more freedom than a framework. But it's a 2-sided medal with incompleteness on the other side. It took me quite some time to appreciate React after my encounter with Angular.
What made you finally appreciate the lib?
JSX. I think it's a brilliant concept to build HTML in JS with syntactic sugar that looks like HTML. It's so powerful and yet so simple compared to building HTML in HTML with a special templating language on top or additional HTML tags that you must learn specifically for your framework.
Hatem, will you please tell us: what was the hardest thing for you while switching from Angular to React? I've been using ng for 3 years and interested in trying React. But I have some fear of its complexity. When I see articles about hooks, JSX, all that stuff... Was is that hard?
I was doing a simple application so nothing was really hard other than getting used to the structure of the project and writing jsx. React has great documentation, you can start from there.