Réactivité des frameworks front-end : React, Vue, Angular comparés !

Qu'est-ce que la réactivité ?

La réactivité est un principe de programmation qui, pour faire simple, signifie que lorsqu'une donnée change, toutes les parties qui en dépendent se mettent à jour automatiquement. On peut un peu le voir comme une feuille Excel : à la modification d'une cellule, toutes les formules qui l'utilisent se recalculent instantanément.

Pourquoi les frameworks ont-ils besoin de réactivité ?

Avant de rentrer dans le vif du sujet et pour poser les bases, on vous conseille notre épisode de podcast sur l'état des frameworks JS en 2026  !

Le contexte historique

Avant les frameworks modernes, chaque mise à jour de l'interface devait être programmée manuellement. Le développeur devait gérer lui-même trois aspects essentiels :

• Détecter quand une donnée change
• Identifier quoi mettre à jour dans l'interface
• Mettre à jour le DOM

Dans les faits, même s'il n'était pas rare que les développeurs construisent leur propre framework maison pour faciliter le travail (mais compliquant souvent l'onboarding…), cette approche posait quand même plusieurs problèmes de gestion :

• Maintenabilité : Le code devient vite complexe et difficile à maintenir
• Fiabilité : Risque d'oublier de mettre à jour certains éléments
• Performance : Difficulté d'optimiser les mises à jour

Les problèmes du JavaScript vanilla

JavaScript Vanilla : Voici trois exemples pour voir la complexité croissante d'une solution "manuelle":

Problème 1 : Un simple compteur

let count = 0;
const btn = document.querySelector('#button');
btn.addEventListener('click', () => {
  count++;
  btn.innerText = `Count: ${count}`; // Mise à jour manuelle
});

Problème 2 : Plusieurs éléments dépendants

let count = 0;
const btn = document.querySelector('#button');
const list = document.querySelector('#list');

btn.addEventListener('click', () => {
  count++;
  btn.innerText = `Count: ${count}`;        // Mise à jour 1
  list.append(createItem(`Item ${count}`)); // Mise à jour 2
});

Problème 3 : Plusieurs sources de changement

let count = 0;
const addBtn = document.querySelector('#add');
const removeBtn = document.querySelector('#remove');

function updateAll() {
  addBtn.innerText = `Add: ${count}`;
  removeBtn.innerText = `Remove: ${count}`;
}

addBtn.addEventListener('click', () => {
  count++;
  updateAll(); // À ne pas oublier !
});

removeBtn.addEventListener('click', () => {
  count--;
  updateAll(); // À ne pas oublier !
});

Plus l'application grandit, plus la gestion manuelle devient ingérable. On doit penser à chaque mise à jour, dans chaque fonction, pour chaque élément → difficile à developper et difficile à review : une erreur peut vite se glisser en production.

C'est là que les frameworks deviennent utiles, ils permettent d'automatiser cette synchronisation entre données et interface.

Réactivité des frameworks : deux philosophies

Avant de regarder plus en détail l'aspect technique, il faut comprendre qu'il existe deux grandes approches à la réactivité :

#1 : Réactivité à l'exécution (Runtime)

Les frameworks comme React, Vue et Angular incluent un moteur de réactivité qui tourne pendant que l'utilisateur navigue sur la page. Ce moteur :

• Surveille les changements de données
• Compare l'ancien et le nouvel état
• Met à jour l'interface en conséquence

Cela a plusieurs avantages :

• Flexibilité : L'application peut s'adapter dynamiquement
• Debugging plus facile : Le code ressemble à ce qui s'exécute
• Moins de contraintes sur le code.

Mais aussi plusieurs inconvénients :

• Bundle plus lourd : Le moteur de réactivité augmente la taille de l'application
• Overhead à l'exécution : Coût en performance pendant l'utilisation

#2 : Réactivité à la compilation (Compile-time)

Svelte, un framework plus récent qui a su se faire remarquer rapidement, adopte une philosophie radicalement différente : il analyse le code pendant la compilation et génère du JavaScriptLangage de scripting orienté objet optimisé qui met à jour le DOM de manière chirurgicale.

<script>
  let count = 0;
</script>

<button on:click={() => count++}>
  Count: {count}
</button>

Le compilateur de Svelte transforme ce code en quelque chose comme :

let count = 0;
const button = document.createElement('button');

function update() {
  button.textContent = `Count: ${count}`;
}

button.addEventListener('click', () => {
  count++;
  update(); // Le compilateur sait exactement quoi mettre à jour
});

Les avantages de la réactivité compile-time :

• Pas de moteur de réactivité dans le bundle final
• Performance optimale : code généré proche du vanilla JS optimal
• Bundles plus légers

Les inconvénients :

• Moins de flexibilité dynamique
• Nécessite une étape de compilation

Cette distinction est fondamentale car elle influence l'architecture, les performances et l'expérience développeur de chaque framework.

Comment les frameworks runtime gèrent la réactivité

Si l'on se concentre sur les trois principaux frameworks du moment (ReactReact est un framework de développement JavaScript populaire., Vue et AngularAngular est un framework de développement JavaScript populaire basé sur TypeScript.), on peut remarquer des différences majeures, et cela même s'ils utilisent tous les trois la compilation au run-time (à l'exécution).

Vue : Proxies JavaScript

Vue 3 utilise les Proxies pour intercepter automatiquement les lectures et écritures :

const count = ref(0); // Vue enveloppe la valeur dans un Proxy

// Quand count.value est lu, Vue enregistre la dépendance
// Quand count.value est modifié, Vue sait quoi mettre à jour

Exemple :

<script setup>
import { ref } from "vue";
const count = ref(0);
</script>

<template>
  <button @click="count++">Count: {{ count }}</button>
</template>

Fonctionnement :

1. Vue enveloppe count dans un Proxy
2. Quand le template lit count, Vue enregistre cette dépendance
3. Quand count++ s'exécute, le Proxy intercepte et déclenche une mise à jour

React : setState et batching

React nous demande à nous, développeurs, de signaler explicitement les changements via des setters :

const App = () => {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Count: {count}
    </button>
  );
};

Fonctionnement :

1. setCount() signale un changement à React
2. React batche plusieurs changements ensemble
3. React re-rend le composant avec la nouvelle valeur
4. React compare le nouveau Virtual DOM avec l'ancien
5. React applique uniquement les changements nécessaires au DOM réel

Un peu comme un serveur au restaurant, qui attend d'avoir plusieurs commandes pour faire un aller-retour en cuisine. Dans ce cas, certains clients (ici des bout de notre application) peuvent être obligés d'attendre quelque temps.

Angular : De Zone.js vers les Signaux

Historiquement, Angular utilisait Zone.js qui interceptait tous les événements asynchrones (clics, requêtes HTTP, timers) et lançait un cycle de détection de changements sur toute l'application.

Depuis Angular 16, notre code a pu être simplifié grâce aux signaux qui offrent une approche plus moderne et performante :

@Component({
  selector: 'app-root',
  standalone: true,
  template: `
    <button (click)="count.set(count() + 1)">
      Count: {{ count() }}
    </button>
  `,
})
export class AppComponent {
  count = signal(0);
}

Les signaux permettent une réactivité qualifiée de fine-grained, similaire à Vue, avec de meilleures performances.

Quel est le meilleur choix ?

Encore une fois, il n'y a pas de "meilleur" framework, seulement des frameworks plus ou moins adaptés à une situation. Tout n'est que compromis, concernant :

• la taille du bundle,
• les performances,
• le debugging,
• la maturité,
• l'écosystème

Le choix dépend alors du contexte. Performance critique ? Écosystème mature nécessaire ? Taille de l'équipe ? Connaissances et préférences de l'équipe ?

C'est à chaque équipe d'adapter ses choix en fonction du projet.

Réactivité des frameworks : ce qu'il faut retenir

En simplifiant la synchronisation entre l'état de l'application et sa vue, la réactivité a transformé notre façon de développer des applications web. Les solutions techniques divergent cependant sur deux points critiques : la détection du changement (quand) et le ciblage de la mise à jour (quoi).

Parmi les (très) nombreux frameworks web, certains préfèrent s'appuyer sur un moteur d'exécution et d'autres favorisent une étape de compilation préalable, ce qui impact forcément les performances.

Au-delà de ces clivages techniques, le framework reste un simple outil au service des développeurs. Le choix du framework doit donc dépendre du type de projet, des contraintes métiers, de la maturité du framework et des performances attendues. L'enjeu n'est pas de choisir l'outil le plus populaire, mais celui qui offre le meilleur équilibre entre confort de développement et efficacité technique.

Un projet ? Besoin de conseils ? N'hésitez pas à contacter l'équipe AXOPEN !