Vous n'avez pas besoin de NextJS
Next.js est la réponse par défaut pour construire des applications React. C'est un excellent framework. Mais "par défaut" ne signifie pas "nécessaire".
L'utiliser pour le mauvais projet nous a coûté en rapidité et a créé des frictions au sein de l'équipe. Nous avons construit un produit riche en données avec des tableaux de bord et des graphiques. Presque chaque écran était protégé par une connexion.
Pour ce type d'application, le rendu côté serveur (SSR) a ajouté des coûts sans apporter de valeur ajoutée.
Le bon outil dépend de ce que vous construisez.
Projets axés sur le contenu : • Sites marketing • Blogs • Boutiques en ligne • Documentations • Utilisez Next.js ici. Le SEO est important et le contenu est statique.
Projets axés sur l'application : • Outils internes • Tableaux de bord • Panneaux d'administration • Consoles SaaS • Utilisez une SPA basée sur Vite ici. Ces applications sont protégées par une authentification et s'appuient sur des API.
Nous sommes passés de Next.js à une SPA basée sur Vite. Voici pourquoi :
Débogage plus facile Les erreurs serveur ne correspondent pas toujours clairement à vos composants. Les erreurs côté client se produisent dans le navigateur avec des traces de pile (stack traces) explicites. Cela permet de corriger les bugs rapidement.
Meilleurs tests Il est difficile de tester unitaire un composant serveur qui en rend d'autres également côté serveur. Nous avons fait des choix de conception uniquement pour rester testables. C'était une erreur.
Authentification plus simple Le SSR exige que le serveur valide les jetons à chaque requête. Cela crée davantage de surfaces d'attaque et une logique de cookies complexe. Une application axée sur le client gère l'authentification à un seul endroit : l'API.
Coûts d'infrastructure réduits Le SSR nécessite un serveur toujours actif pour chaque requête. Un frontend statique est déployé sous forme de fichiers via un CDN. Vous avez un service de moins à gérer et à sécuriser.
Moins de complexité Next.js impose une séparation entre le serveur et le client. Les ingénieurs frontend devaient gérer des problématiques serveur comme le middleware et la mise en cache. Cela nous a ralentis.
Nous avons migré par étapes. Nous avons conservé Next.js pour les pages publiques critiques pour le SEO. Nous avons migré tout le reste vers une SPA basée sur Vite.
Les compromis étaient minimes : • SEO : Les tableaux de bord derrière une connexion n'ont pas besoin de SEO. • Chargement initial : Les applications riches en données sont généralement lentes à cause de la base de données, pas du framework.
Utilisez Next.js si le SEO et les aperçus sur les réseaux sociaux sont importants. Utilisez une SPA basée sur Vite si votre application est interactive, pilotée par les données et protégée par une connexion.
Arrêtez d'utiliser la solution par défaut. Demandez-vous ce que vous construisez réellement.
Source : https://dev.to/moruno21/you-dont-need-nextjs-heres-why-708