Next.js vs React : ce que Next apporte et quand vous en avez besoin
Next.js vs React
Next.js vs React : bibliothèque ou framework, quand Vite suffit | We.Inc
React est une bibliothèque d'interface ; Next.js est un framework construit dessus. Cochez les fonctionnalités dont votre projet a besoin et voyez si Next.js ou React seul avec Vite convient, avec du code pour les deux.
React est une bibliothèque pour construire des interfaces à partir de composants. Next.js est un framework qui utilise React et ajoute le routage basé sur les fichiers, le rendu côté serveur, les server components, les endpoints d'API et l'outillage de build. Vous écrivez du React dans les deux cas. Choisissez Next.js quand les pages ont besoin de HTML rendu côté serveur, de secrets ou de routes backend ; React seul avec Vite convient aux applications derrière une connexion.
Ce que vous obtenez d'emblée
Besoin
React avec Vite
Next.js (App Router)
Composants, état, hooks
Oui
Oui, le même React
Routage
Ajouter une bibliothèque de routage
Les dossiers de app/ deviennent des routes
HTML rendu avant le chargement du JavaScript
Non, sauf si vous ajoutez du SSR ou du prérendu
Oui, côté serveur ou au build
Server components et secrets côté serveur
Non
Oui, les layouts et pages sont des server components par défaut
Endpoints d'API dans le même projet
Non, backend séparé
Fichiers route.ts
Sortie
Fichiers statiques issus de vite build
Serveur Node, ou fichiers statiques avec output: 'export'
Cochez les fonctionnalités dont votre projet a besoin. Chacune est indiquée comme intégrée à Next.js ou facile dans une application React avec Vite, et le décompte vous donne une recommandation de départ. Le code ci-dessous montre la même petite page écrite des deux façons.
Cochez chaque fonctionnalité dont votre projet a besoin maintenant, pas un jour peut-être.
Voyez de quel côté penche chaque fonctionnalité et pourquoi.
Lisez le décompte et la recommandation sous la liste.
Comparez les deux exemples de code pour voir ce qui change.
Vos connaissances React se transposent entièrement. Composants, hooks et JSX sont identiques ; ce qui change, c'est l'emplacement des fichiers et l'endroit où le code s'exécute.
Dans Next.js, ajoutez 'use client' uniquement aux fichiers qui ont besoin d'état, d'effets ou d'API du navigateur. Marquer tout un layout comme client envoie beaucoup plus de JavaScript.
Une application Vite, ce sont des fichiers statiques : elle peut donc être hébergée sur n'importe quel hébergeur statique. Une application Next.js qui utilise des fonctionnalités serveur a besoin d'un hébergeur qui exécute Node ou l'adaptateur de plateforme que vous choisissez.
Si le trafic issu de la recherche compte, vérifiez ce que votre page envoie avant l'exécution du JavaScript. Affichez la source d'une single page app Vite et vous verrez surtout une div racine vide.
Questions fréquentes
Next.js est-il meilleur que React ?
Ce ne sont pas des alternatives au sens habituel, car Next.js fait tourner React. La vraie question est de savoir si vous voulez le routage, le rendu serveur et les conventions d'un framework, ou une configuration plus légère où vous choisissez chaque brique vous-même.
L'équipe React recommande-t-elle encore Create React App ?
Le guide actuel de react.dev recommande de démarrer avec un framework comme Next.js ou React Router, et cite Vite, Parcel et Rsbuild pour construire votre propre configuration de zéro. Il ne mentionne pas Create React App.
Next.js peut-il produire un site statique comme Vite ?
Oui. Définissez output: 'export' dans next.config.js et next build écrit le HTML, le CSS et le JavaScript dans un dossier out. Les fonctionnalités qui nécessitent un serveur actif, comme les cookies, les rewrites, les redirections et les server actions, ne sont pas disponibles dans ce mode.
Faut-il apprendre React avant Next.js ?
Apprenez d'abord les bases de React : composants, props, état et effets. Next.js ajoute ensuite le routage et les notions serveur par-dessus, et le débogage est bien plus simple quand vous savez à quelle couche appartient chaque problème.
Une application React avec Vite est-elle mauvaise pour le SEO ?
Pas automatiquement, mais par défaut le HTML ne contient aucun contenu de page tant que le JavaScript ne s'est pas exécuté. Les pages marketing qui doivent se positionner sont plus faciles avec du rendu serveur ou du prérendu ; les tableaux de bord derrière une connexion n'en ont pas besoin.
Bibliothèque ou framework
React décide comment un composant transforme l'état en interface et met à jour la page. Il ne décide pas comment les URL correspondent aux écrans, où les données se chargent ni comment le projet est compilé. Ces choix vous reviennent dans une application Vite et reviennent à Next.js dans une application Next.
Voilà le compromis : Next.js supprime des décisions et ajoute des fonctionnalités serveur, et en échange vous suivez ses conventions de dossiers et utilisez son build.
Ce qui change dans votre code
Dans Next.js, app/blog/page.tsx est la route /blog et layout.tsx enveloppe ses enfants. Les pages sont des server components sauf indication contraire, elles peuvent donc attendre les données directement, et les parties interactives vivent dans des fichiers qui commencent par 'use client'.
Dans une application Vite, main.tsx rend un composant racine dans index.html, les routes viennent d'une bibliothèque comme React Router, et les données se chargent dans le navigateur via fetch ou un cache client.
Quand React seul avec Vite suffit
Les outils internes, tableaux de bord, éditeurs et tout ce qui se trouve derrière une connexion ont rarement besoin de HTML rendu côté serveur. Une application Vite démarre vite, se déploie sous forme de fichiers statiques et garde un modèle mental simple.
Si une telle application a besoin plus tard de pages publiques, il est courant de placer les pages marketing sur un site séparé et de garder l'application telle quelle.
La même page, des deux façons
Next.js : une route qui charge les données côté serveur
Le chemin du fichier est l'URL. La page attend les données avant l'envoi du HTML ; seul le bouton est envoyé en JavaScript client.
React avec Vite : la même liste chargée dans le navigateur
Le routage vient de React Router, et la liste apparaît une fois que le navigateur l'a récupérée.
Démarrer l'un ou l'autre projet
Les deux commandes posent quelques questions, notamment s'il faut utiliser TypeScript.
Pages publiques qui doivent se positionner dans la recherche
Le HTML généré côté serveur ou au build place le contenu dans la première réponse.
Requêtes en base de données ou clés d'API utilisées pendant le rendu
Les server components gardent les identifiants hors du bundle du navigateur.
Endpoints backend dans le même projet
Les fichiers route.ts deviennent des endpoints d'API.
Nombreuses pages de contenu avec des layouts partagés
Le routage par dossiers et les layouts imbriqués sont intégrés.
Tout se trouve derrière une connexion
Les robots ne le voient jamais, le rendu dans le navigateur convient donc.
L'hébergement doit se faire en simples fichiers statiques
vite build produit des fichiers statiques ; Next.js le peut aussi, mais perd ses fonctionnalités serveur.
Un widget ou un outil intégré dans un autre site
Un seul bundle et un seul élément racine sont plus simples à insérer.
Apprendre React lui-même
Moins de notions à la fois : pas de séparation serveur et client à comprendre.
Qu'est-ce qui convient à votre projet ?
Besoins du projet
React avec Vite
Next.js : {n}. React avec Vite : {v}.
Cochez au moins un besoin pour obtenir une recommandation.
Penchez pour Next.js. Vos besoins dépendent du rendu serveur ou de code serveur.
React seul avec Vite suffit. Vous pourrez ajouter un framework plus tard si des pages publiques apparaissent.
C'est serré. Choisissez Next.js si une page publique doit se positionner ; sinon, commencez avec Vite.