How I became a conference speaker (and how you can too!)
This is how I got into conference speaking as a software engineer, and how you can too.
The eternal debate: Angular vs. React. It's like pineapple on a pizza, a discussion that never ends.
Nicky Haze - 6 min read
The eternal debate: Angular vs. React. It's like pineapple on a pizza, a discussion that never ends. Angular and React are two heavyweights in the JavaScript world. Both are very popular and have evolved a lot over the years. Looking at Angular 18 and React 19 I often hear people asking: "Is Angular starting to look like React?".
Well, spoiler alert: no.
If you squint hard enough, Angular does feel less "old school" than before. But this doesn't mean they're trying to look like React. Let's break this apart and show their key differences.
Before diving into comparing the two, let’s quickly recap on both Angular and React:
Angular is a complete framework. It gives you (nearly) everything: routing, HTTP client, forms, services, dependency injection (DI), and even more, all included into the core framework. You don't need to go hunting for third-party libraries to get started.
React, on the other hand, is "just" a library. It's all about the components. Want routing? Go grab react-router. Need state management? Here comes redux. React's philosophy is to stay lean and let the ecosystem fill the gaps.
TL;DR: Angular is a framework, React is a library. Angular is like building with pre-made blueprints. React is like constructing something from scratch. And that’s a huge difference.
Angular uses a HTML-first syntax, where the templates are traditional HTML combined with Angular's control flow syntax. Angular's HTML syntax focuses on separating template (HTML) from logic (TypeScript).
// my-component.component.ts import { Component } from '@angular/core'; @Component({ selector: 'app-my-component', templateUrl: './my-component.component.html' }) export class MyComponent { showTitle = true; username = 'Nicky Haze'; }
// my-component.component.html @if (showTitle) { <h1>Welcome, {{ username }}!</h1> }
React goes for a more integrated approach with JSX (JavaScript XML), which can seem a bit unconventional at first. JSX lets you write HTML-like code directly inside your JavaScript. Instead of separating logic and templates into different files or blocks, JSX merges those two. While it looks similar to HTML, it's fundamentally JavaScript underneath the hood. The end result is a tightly coupled combination of both rendering and logic within the same code block.
import React from 'react'; const showTitle = true; const username = 'Nicky Haze'; const MyComponent = () => { return ( <> {showTitle && <h1>Welcome, {username}!</h1>} </> ); }; export default MyComponent;
Angular and React are different when looking at their data binding mechanisms.
Angular makes it possible to use both one-way and two-way data binding, with two-way data binding especially in form templates. This allows changes in the model or user interface to automatically update each other. The two-way binding syntax, [()]
, combines property binding []
and event binding ()
. It's informally called "banana-in-a-box".
React uses one-way data binding. Props go down, actions come up. It's strict, predictable and easy to debug.
Example:
// two-way data binding <input [(ngModel)]="name"> // one-way data binding <input [value]="name" (change)="setName($event)">
<input value={name} onChange={(e) => setName(e.target.value)} />
React uses virtual DOM. This means it calculates what needs to change in the UI before touching the actual DOM. It's efficient and fast, but you end up with a "React reality" that's abstracted from the real DOM.
Angular interacts directly with the real DOM. This approach can be less efficient compared to React's virtual DOM, but then uses a more accurate representation of the application's state. To prevent performance issues Angular came up with various optimization techniques, such as change detection strategies and lazy loading.
Signals is Angular's new way to handle asynchronous data and their change detection. This feature was first introduced in Angular 16 as a developer preview, and its final version was released in Angular 17.
// counter.component.ts import { Component, signal } from '@angular/core'; @Component({ selector: 'app-counter', templateUrl: './counter.component.html' }) export class CounterComponent { count = signal(0); increment() { this.count.set(this.count() + 1); } decrement() { this.count.set(this.count() - 1); } }
// counter.component.html <div> <p>The count is: {{ count }}</p> <button (click)="increment()">+</button> <button (click)="decrement()">-</button> </div>
One of the most groundbreaking features in React is hooks, introduced in React 16.8. React uses hooks as a way to manage local state and side effects in functional components. It's all about functions and closures (classic React).
import { useState } from "react"; const Counter = (props) => { const [count, setCount] = useState(0); function increment() { setCount(count + 1); } function decrement() { setCount((prevCount) => prevCount - 1); } return ( <div> <p>The count is: {count}</p> <button onClick={increment}>+</button> <button onClick={decrement}>-</button> </div> ); }; export default CounterComponent;
Signals might seem quite similar to React's hooks (especially useState and useEffect). Signals allow Angular components to react to data changes, kind of like what React components do with state. But here's the thing: it's not the same!
Let's face it: Angular's dependency injection is one of its biggest strengths. In Angular, services can be injected everywhere, from components to modules, with clear lifecycle management.
React does not come with a built-in dependency injection system. Instead, developers often use patterns like Context API, hooks, or other external libraries.
Let's put this debate to rest. Angular 18 and React 19 may look similar at a glance if you've only checked the docs or a Medium article, but under the hood, they are fundamentally different.
Can you love both? Absolutely! I do. But Angular will never be React, and React will never be Angular, and that's perfectly fine. Because why would you want two identical tools in your toolbox? Keep Angular for when you need to build something from scratch with an integrated solution and keep React for when you want to build something quick and modular.
In the end, saying Angular is copying React is like saying that Dutch football club Feyenoord is copying football club Ajax because they both have a huge amount of fans and both wear red and white outfits.
So let's not say Angular is starting to look like React, because that's just nonsense.