- Résultats obtenus en migrant le tableau de bord de ComfyDeploy de Next.js vers React :
- temps de build réduit de 3 minutes à 18 secondes
- hot reload amélioré à moins de 200 ms
- une équipe beaucoup plus satisfaite
- Au départ, nous avions lancé une application full-stack avec Next.js, et grâce à Drizzle et aux Server Actions, elle fonctionnait bien avec une bonne sûreté de typage et un code propre. Mais nous avons rencontré les problèmes suivants :
- 2 000 $ de coûts d’API sur Vercel causés par un utilisateur en particulier
- complexité accrue des tests d’API : mélange de Server Actions et de routes API
- temps de build lents et environnement de développement local inefficace
- rechargement SSR complet au moindre petit changement
- Problèmes
- complexité croissante de Next.js : l’approche tout-en-un (full-stack) de Next.js a entraîné une complexité de développement à mesure que l’application grandissait
- notre tableau de bord repose principalement sur React et n’a pas besoin des fonctionnalités serveur de Next.js
- Passage de Next.js à React
- migration de Next.js vers React avec TanStack Router et Rspack
- démarrage du serveur de développement : moins de 2 secondes
- temps de build sur Vercel : 18 secondes
- amélioration de la configuration de l’API, suppression des dépendances inutiles, simplification du code et hausse de la productivité
- migration de Next.js vers React avec TanStack Router et Rspack
- Comparaison des performances
- Next.js 15 (avec le mode Turbo)
- build de la première page : 10,4 secondes
- React + TanStack Router + Rspack
- calcul des routes : moins de 200 ms
- build du bundle initial : 1,67 seconde
- Next.js 15 (avec le mode Turbo)
- Compromis
- Ce que nous avons perdu
- co-location du code frontend et backend : en séparant le frontend et le backend, les frontières sont devenues plus claires
- fonctionnalités de cache de Next.js : comme nous avons beaucoup de données mises à jour en temps réel, nous les avons remplacées par un cache sur mesure
- pré-rendu et chargement initial : mise en place d’une meilleure UX au lieu de la Static Generation — plus de boutons désactivés affichés
- composants et actions serveur : nous avons perdu la « magie » des composants serveur, mais gagné avec une conception d’API plus intentionnelle
- Ce que nous avons gagné
- une conception plus solide des contrats d’API
- une mise en cache uniquement là où elle est nécessaire
- une conception réfléchie des flux de données et de la gestion d’état
- Ce que nous avons perdu
- Conclusion
- Next.js convient bien aux landing pages et à des tâches comme le SEO, mais il apporte une complexité excessive pour la plupart des produits
- nous continuons à utiliser Next.js pour les landing pages et le SEO
- le tableau de bord a été migré vers Pure React + TanStack Router + Rspack
- l’API s’exécute sur un serveur Python FastAPI sur Google Cloud Run avec mise à l’échelle automatique selon les besoins
- Il est important de choisir le bon outil, et pour nous, Next.js était un choix excessif
17 commentaires
Au moment où notre entreprise préparait l’unification et la migration du front avec Next.js, tomber sur un article comme celui-ci me donne matière à réflexion....
Nous n’exploitons que des services où l’approche mobile « app » first est possible, donc pour les parties qui ont besoin de SEO, nous n’utilisons pas du tout React (ou quelque chose de similaire) et nous gardons cela très léger.
Le web n’est utilisé que pour attirer via le SEO, puis pour rediriger vers l’app...
« Il est important de choisir l’outil adapté, et pour nous, Next.js était un choix excessif. »
J’ai l’impression que la dernière phrase est l’essentiel.
Pour choisir l’outil adapté, je pense qu’il est aussi important d’avoir accumulé beaucoup d’expériences d’échec de toutes sortes.
Si le SEO est nécessaire, c’est que le contenu est au cœur du sujet,
mais comme ce sont les composants d’UI (?) et l’état qui occupent la place centrale… des créatures étranges comme SSR, ISR, Hydrate… sont nées…
Je trouve ce point de vue très pertinent.
Personnellement, sauf si le SEO est nécessaire, je n’adopte jamais Next.js.
Comme dans l’article ci-dessus, n’utiliser que React présente de nombreux avantages :
Je ne sais pas trop, mais apparemment il y a une grosse différence en temps de build.
On dirait que vous ne saviez pas encore que React est bien plus lent que les autres frameworks.
Parce que la vitesse n’est pas si importante. Si la vitesse était importante,
expressjsserait encore utilisé. La communauté et les bibliothèques sont largement plus nombreuses.On dirait que l’accent est mis sur la migration de Next vers React haha
La communauté React a abandonné CRA dès les débuts pour passer aux frameworks, donc je ne sais pas si aller à contre-courant est vraiment un choix facile.
La plupart ont migré vers Vite, et nous utilisons toujours des frameworks selon les besoins, même aujourd’hui.
C’est ce qui est indiqué sur react.dev~
C’est intéressant. Next est-il plus lourd que React ?
Je n’ai fait que configurer un projet avec Next, mais la mise en place du projet et le démarrage du développement avaient été extrêmement simples.
"Simplement" <= pour y parvenir, beaucoup de magie (?) est cachée, au prix de nombreux compromis.
Je comprends. Il y a énormément de dépendances cachées sous le capot de Next.js...
Commentaires sur Hacker News
Beaucoup de gens se concentrent trop sur la capacité d’une idée à passer à l’échelle pour des milliards d’utilisateurs. On voit donc des cas où quelqu’un utilise Kubernetes alors que son site web n’a que 5 visiteurs. J’ai aussi vu des étudiants utiliser Next.js pour créer des sites qui auraient pu être faits simplement en HTML + CSS
J’ai construit des projets avec Next.js, mais son utilisation m’a semblé complexe. L’API d’accès aux cookies diffère entre le client et le serveur, et devoir accéder aux variables d’environnement via
process.env.NEXT_PUBLIC_*est déroutant. Je voulais pouvoir écrire du code qui fonctionne côté client et côté serveur avec un minimum de changements, mais ce n’était pas le cas. J’ai eu l’impression que l’apprentissage et la surcharge ne valaient pas ce que Next.js apporteLa base de code est devenue plus simple et le rendu des pages plus rapide. C’est dommage que la communauté soit poussée inutilement vers ce genre de framework. La plupart des gens n’ont besoin que de
npx rsbuild init. Avec rspack et rsbuild, j’ai obtenu un routeur simple et une belle simplicitéJ’utilise Next.js depuis la sortie de la v14, et j’en suis très satisfait. Avec les RSCs, une grande partie de l’application fonctionne bien même si le JS côté client est désactivé. On retrouve la puissance simple d’une application PHP, tout en pouvant intégrer de façon fluide le système de types et des composants client interactifs basés sur l’état au niveau des « feuilles » de l’arbre de vue
Grâce à Rails et Hotwire, j’ai pu sortir de la confusion de l’écosystème React. Il y a trop de choix : bibliothèques de gestion d’état, méta-frameworks, bibliothèques de data fetching, etc. Il n’est pas nécessaire de compliquer la tâche simple qui consiste à afficher sur une page des données venant du serveur
Je travaille sur un CMS (PayloadCMS) qui utilise NextJS, et NextJS est la pire technologie que j’aie jamais utilisée
Presque tous les projets qui utilisent des frameworks/bibliothèques frontend lourds comme Next.js, React ou Vue feraient mieux d’utiliser une bibliothèque qui gère les templates côté backend. Parfois, le rendu côté client via EJS a du sens. Je me demande pourquoi on utilise ces frameworks
J’utilise Next.js pour le SEO et l’optimisation du crawling. Si une page n’a pas besoin d’être crawlée (par exemple un dashboard derrière connexion), alors Next.js n’est pas nécessaire et du React pur sera plus simple
Je suis surpris que Next.js soit devenu l’option de départ par défaut. Ça ressemble à un grand changement par rapport à il y a 2 ou 3 ans
J’essaie de remplacer une application NextJS avec Vike, et j’en suis satisfait. Je peux construire comme je le veux, sans être entravé
Kubernetes pour une appli avec 5 utilisateurs... impressionnant.