- Le middleware de Next.js offre des options de configuration de logging limitées, et le logging par défaut n’est activé qu’en environnement de développement, ce qui complique le suivi des problèmes en production
- Dans le middleware, seuls les en-têtes peuvent être transmis, et il est impossible d’enchaîner plusieurs middlewares, ce qui limite la mise en place d’un logging complexe
- Le logging avec AsyncLocalStorage a un comportement inattendu dans le runtime Edge, et le partage de contexte entre les pages et le middleware ne fonctionne pas correctement
- Même avec un serveur personnalisé, il est difficile de résoudre les problèmes de logging, et les contraintes de conception de Next.js forcent les développeurs à adopter une certaine manière de faire
- Le SvelteKit de Vercel propose un middleware plus flexible et des mécanismes de transmission de données, avec une conception plus favorable aux développeurs que Next.js
Contexte du problème de logging dans Next.js
- En exploitant un service Next.js et en essayant de mettre en place des logs de production, l’auteur a constaté que les fonctions de logging intégrées n’étaient activées qu’en développement
- Alors qu’un système de logging adapté à la production était nécessaire, il s’est heurté aux limites de Next.js
Les limites du middleware
- D’après la documentation officielle, le middleware s’exécute avant le routage et convient à l’implémentation de fonctions comme l’authentification, le logging ou les redirections
- En pratique, les paramètres transmissibles au middleware sont limités à quatre, et seuls les en-têtes peuvent réellement être transmis
- La structure ne prend pas en charge l’enchaînement ou la composition de plusieurs middlewares
- Dans l’écosystème Node.js, il existe des pratiques de middleware bien établies, notamment avec Express, mais elles ne peuvent pas être correctement appliquées dans Next.js
Tentative de contournement avec AsyncLocalStorage
- Tentative de gestion d’instances de logging au niveau du middleware avec pino et AsyncLocalStorage
- Il est possible d’enregistrer des logs avec un contexte unique pour chaque requête dans le middleware, mais il a été constaté que cela ne fonctionne correctement que dans l’environnement du navigateur
- Cela vient du fait que le middleware de Next.js utilise par défaut le runtime edge et que, même configuré avec le runtime nodejs, le comportement reste instable selon le projet
Les blocages dans les composants de page
- Lorsqu’une fonction de logging est appelée dans une page réelle ou un composant de layout, logger() renvoie null
- Il existe un problème structurel : le contexte de logger créé dans le middleware n’est pas transmis au contexte de rendu asynchrone
- La seule solution consiste à transporter les informations de logging comme requestId dans les en-têtes, ce qui complexifie le code et rend aussi la structure des imports confuse
- Une séparation structurelle similaire est également requise dans les composants clients
Tentative d’introduction d’un serveur personnalisé
- En suivant l’exemple de serveur personnalisé dans la documentation officielle, l’auteur a testé l’utilisation de http.createServer et de app.getRequestHandler de next.js
- Il a alors essayé de réutiliser AsyncLocalStorage dans cet environnement, mais l’impossibilité de relier le contexte entre middleware, page et serveur personnalisé s’est répétée
- Fondamentalement, AsyncLocalStorage n’est correctement utilisé qu’à l’intérieur de Next.js, sans offrir les mêmes possibilités aux développeurs
- En pratique, les seuls moyens de transmettre des informations du middleware vers la page sont la modification des en-têtes de réponse ainsi que les redirections/réécritures de route
- Du point de vue de l’utilisateur, il est donc très difficile d’étendre le comportement ou de transmettre un contexte personnalisé de manière souple
Comparaison avec SvelteKit
- Le SvelteKit de Vercel propose un système de middleware plus flexible que Next.js
- L’objet event.locals permet de transmettre librement les données de requête
- Il est possible de définir plusieurs fonctions handle et de les enchaîner, ce qui facilite l’implémentation d’une logique complexe
- SvelteKit illustre une conception favorable aux développeurs, en contraste avec les contraintes de Next.js
- Bien que SvelteKit soit aussi un produit de Vercel et soit considéré comme un projet secondaire par rapport à Next.js, il offre malgré tout une meilleure expérience
Critique de l’issue tracker et de la culture de l’écosystème
- Le GitHub issue tracker officiel de Next.js répond très peu aux retours des utilisateurs
- Même des issues populaires ou des bugs peuvent rester longtemps sans réponse ni correction
- Même en préparant un code minimal de reproduction et en ouvrant une issue, il n’y a souvent ni réponse concrète ni suivi
Conclusion et remise en question
- Les bugs et limites structurelles constatés dans Next.js nuisent de manière répétée à la productivité des développeurs et appellent des améliorations de fond
- Comparé à d’autres frameworks comme SvelteKit, Next.js reste en retrait sur l’utilisabilité alors même qu’il s’agit du produit principal
- Il est difficile d’envisager de remplacer Next.js immédiatement, mais cela donne envie d’étudier d’autres options pour de futurs projets
7 commentaires
On dirait qu’ils n’ont toujours pas réalisé que React nuit à la productivité.
Cette fois, j’ai essayé le développement web par simple intérêt personnel, un domaine qui n’a absolument rien à voir avec celui dans lequel je développais à l’origine. J’ai créé un forum avec le
app routerde next.js v15… mais à chaque fois que je vois ce genre de post, j’ai l’impression que ça me coupe toute envie de tenter quelque chose de nouveau côté web. Pourquoi l’écosystème est-il si instable ? Et puis quoi, si un nouveau truc sort, tout le monde va encore se ruer dessus, l’utiliser un peu, le critiquer, puis repartir chercher autre chose ? Le développement web a vraiment l’air difficile.Le fait que les changements soient rapides est à la fois un avantage et un inconvénient dans ce secteur, haha. Mais le problème évoqué dans le corps du texte vient fondamentalement du bazar semé par Vercel. Si vous faites du front-end, il vaut mieux garder un œil attentif sur Vercel, snif snif.
C’est peut-être parce que j’ai commencé ma carrière dans le web, mais le web — surtout le front — se développe à l’origine avec ce petit goût-là (rires)
Ce goût du changement permanent...
Le côté JS donne un peu cette impression. Il y a tout un tas de choses censées être bien, mais chacune a un peu ses problèmes, et ça change très vite au gré des modes...
C’est peut-être aussi parce que j’ai surtout travaillé avec Java, EJB et Struts, donc c’est comme ça que je le ressens.
Réactions sur Hacker News
Je suis d’accord à 100 %, j’ai eu exactement les mêmes problèmes et je n’utiliserai plus jamais Next.js à l’avenir ; je vais aussi recommander à toutes les équipes de ma boîte d’utiliser d’autres alternatives.
Next.js ajoute une énorme couche d’abstraction inutile dans 99,9999 % des projets ; et dans les rares cas où ce genre de chose est vraiment nécessaire, je pense qu’il vaut mieux construire une solution sur mesure avec des composants plus bas niveau.
De toutes les technos que j’ai utilisées, Next.js est de loin la pire.
Je suis vraiment soulagé de ne pas être le seul à penser ça.
J’ai construit une application de production monétisée de complexité intermédiaire avec Next.js ; au début j’utilisais Vercel et Google Firebase, puis je suis passé à de l’auto-hébergement et j’ai remplacé le tout par Pocketbase.
Pocketbase a été la seule expérience correcte ; tout le reste a été absolument horrible.
Complexité infinie, breaking changes permanents, documentation difficile d’accès : rien n’était simple.
Je suis convaincu que si on avait rembobiné les tendances du front-end de ces cinq dernières années pour se concentrer sur l’enseignement correct des technos qui existaient déjà à l’époque, on serait dans une bien meilleure situation aujourd’hui.
J’ai aussi fait pas mal de frontends React complexes ; je n’aime déjà pas beaucoup React, mais Next.js était encore pire.
J’ai aussi créé un CMS en Go et en JS vanilla ; le DX était peut-être un peu moins bon, mais j’avais au moins l’impression de vraiment comprendre ce qui se passait.
Je ne comprends pas pourquoi, avec React et Next.js, six ans plus tard, on doit toujours deviner ce qu’il va se passer.
J’ai acquis de l’expérience pour démêler les nœuds du framework, mais dans l’ensemble ça me donne juste l’impression d’un énorme bazar et d’un mauvais design.
Avec Go, à part les six premiers mois, je n’ai plus jamais eu de surprise, et même les anciennes codebases restent solides.
C’est dommage de ne pas pouvoir avoir ce genre d’expérience côté front-end.
D’après mon expérience, les aspérités de Next.js ne sont pas des bugs, ce sont des fonctionnalités.
J’ai l’impression que tout est fait pour décourager les utilisateurs et les attacher à l’hébergement Vercel.
Je pense que la situation va encore empirer.
Même des plateformes de cours en ligne comme PluralSight poussent désormais uniquement Next.js dans leurs formations React.
Je ne sais pas exactement comment on en est arrivé là, mais nous y voilà.
Dans mon cas, Sharepoint reste un souvenir encore plus sale, donc Next.js n’est que le deuxième pire.
Le plus frustrant avec Next.js, c’est qu’il prétend tout fournir comme les frameworks full stack type Rails, Wordpress ou Meteor, alors qu’en réalité il n’a des opinions que sur les aspects les moins intéressants et les plus limités — middleware, redimensionnement d’images, SSR, etc. — et laisse à l’utilisateur les décisions vraiment importantes, comme la base de données, l’ORM ou le protocole de communication.
En pratique, c’est très différent de Rails/Wordpress/Meteor ; un framework devrait définir l’infrastructure, mais ici c’est l’infrastructure qui finit par dicter le framework.
Sur mon tableau de bord, les principaux postes de consommation sont « Fluid Active CPU » et « ISR Writes », et je paie 20 $ à chaque fois en espérant juste ne pas dépasser les 100 %.
Les noms des métriques sont remplis de jargon qui sonne comme du Star Trek, et comme tout risque encore de changer à la prochaine version majeure, je n’ai même plus envie d’apprendre.
Pas mal de gens de mon entourage qui étaient autrefois fans de Zeit ont fini par migrer leurs projets et leurs clients ailleurs.
Si Vercel me demandait ce qu’il fallait changer dans la prochaine grosse release, je ne pourrais répondre qu’une chose : « Toutes les décisions prises à partir de l’App Router inclus étaient mauvaises. »
Je ne vois pas comment ils peuvent s’en remettre.
Je pense qu’une grande partie des problèmes de Next.js vient du fait qu’on ne sait pas vraiment où le code s’exécute.
Le navigateur, le middleware, edge et node, le SSR : tout est mélangé, et ça crée une complexité énorme.
Ce n’est pertinent que dans les cas suivants :
quand on opère un service B2C mondial et qu’on veut réduire la latence avec des sémantiques edge ;
quand on est prêt à payer l’hébergement coûteux de Vercel ;
quand on a besoin d’une architecture simple, sans tâches en arrière-plan.
Dans tous les autres cas, une SPA react-vite ou un SSR traditionnel comme Rails est bien plus raisonnable.
Je ne suis même pas d’accord avec ces conditions.
Même quand Next.js semble correspondre au besoin, la baisse de productivité et de maintenabilité n’a absolument pas l’air d’en valoir le prix.
J’utilise Lustre de Gleam et je ne reviendrai pas en arrière.
Je pense aussi que la keynote du créateur d’Elm illustre l’exact opposé de Next.js.
https://www.youtube.com/watch?v=sl1UQXgtepE
Je considère Vercel comme un cancer du web moderne.
Ils s’infiltrent dans tout l’écosystème des frameworks, en abusent pour vendre des offres payantes, et prétendent seulement défendre l’open source, la concurrence et l’évolution du web.
Même dans le premier cas, j’ai du mal à croire qu’utiliser Vercel et du SSR résolve réellement les goulots d’étranglement de performance.
La plupart des problèmes de performance viennent de choses élémentaires : bundles beaucoup trop lourds, multitude d’appels API lents, etc.
Faire d’abord du profiling basique, de l’optimisation et de la simplification est bien plus efficace que de complexifier l’architecture.
Je suis d’accord avec l’idée du « problème de savoir où le code s’exécute ».
Avant, je voyais l’universalité de JavaScript comme un avantage, mais maintenant j’ai plutôt l’impression que c’est le problème.
Dans notre boîte, on utilise Inertia.js + Vue : l’ensemble est bien plus simple, on garde la puissance du rendu front, mais le routage est géré à 100 % côté serveur, sans même avoir besoin d’une API séparée.
On peut aussi utiliser Inertia avec React ou Svelte.
Au départ on utilisait Nuxt, mais c’était assez complexe pour devoir faire tourner en parallèle un serveur backend et un serveur frontend, et il était difficile de savoir où le code s’exécutait.
Maintenant, on n’a plus à se poser la moindre question grâce à une séparation claire : PHP côté serveur, JS côté navigateur.
Pour nous, c’est un énorme avantage.
Je trouve que ça résume bien le sujet.
Vercel cherche à optimiser les performances avec les React Server Components, le Partial Pre-rendering, les serveurs edge, le streaming, etc.
Toutes les décisions de design ou d’API un peu étranges viennent de là.
Dans certains cas ça peut aider, mais même un usage mesuré du SSR sur quelques edge functions peut déjà améliorer les choses sensiblement.
Merci pour vos retours.
Nous sommes conscients des problèmes de DX autour de Middleware, et la prise en charge du runtime Node dans la version 15.5 constitue une avancée importante[1].
Si nous pouvions revenir en arrière, nous l’aurions probablement nommé Routing Middleware ou Routing Handler, afin de mieux refléter son rôle d’escape hatch avancé au niveau du routage pouvant être déployé sur le CDN edge.
Si vous avez besoin de logs, vous pouvez utiliser OpenTelemetry et suivre la convention
instrumentation.ts[2].[1] https://nextjs.org/blog/next-15-5#nodejs-middleware-stable
[2] https://nextjs.org/docs/app/api-reference/file-conventions/instrumentation
Merci pour la réponse.
Mais le fait de parler d’instrumentation et d’observability donne l’impression qu’on résout un simple problème de logs en ajoutant encore une autre couche de complexité.
Toutes les applications n’ont pas besoin d’OpenTelemetry.
Je ne comprends pas pourquoi une approche banale du style
logger().info()ne suffit pas.Tous les autres langages et frameworks ont ça ; je ne comprends pas pourquoi c’est si compliqué ici.
Comme l’ambiance ici est plutôt négative, je préfère préciser d’emblée : Next.js est un très bon logiciel, bien adapté à son objectif réel.
Je pense qu’ils ont bien réussi à construire un logiciel qui soutient des millions de sites.
Le problème vient du manque de références détaillées et de documentation : la doc indique ce qui existe, mais beaucoup moins comment l’utiliser concrètement, à quel moment ça s’exécute, quels sont les pièges fréquents, etc.
C’est accueillant pour les débutants, mais ça manque d’explications sur les contextes d’exécution complexes ou la complexité dérivée.
C’est une tendance qu’on voit aujourd’hui dans beaucoup de projets.
Trouver le bon équilibre entre être user friendly et fournir des explications détaillées est extrêmement difficile.
J’espère que ça continuera à s’améliorer.
Pour le dire autrement en une phrase :
L’auteur de ce billet essayait d’appeler des fonctions partout de la même manière sans comprendre les différences entre les domaines.
Les erreurs de Next.js viennent du fait qu’il essaie de fusionner de force des domaines qui sont de nature différente.
Dès qu’on commence à mélanger edge, SSR, Node et client de cette façon, la complexité explose.
La documentation ne peut pas régler ça ; elle ne ferait qu’ajouter encore plus de confusion.
J’ai déjà vu des gens recommander des méthodes d’instrumentation dans les commentaires Reddit.
Si, à la même époque, la documentation avait été différente alors que j’étais en train de configurer opentelemetry sur Next, j’aurais probablement fini par écrire un billet de blog après cette expérience.
Ce n’est pas forcément votre faute, mais presque tous les packages opentelemetry sont marqués comme expérimentaux, donc il est difficile d’avoir confiance pour la production.
Configurer l’instrumentation de pino a aussi été très pénible.
Il faut ajouter
pinoàserverExternalPackagespour que ça fonctionne correctement.L’auto-instrumentation était aussi extrêmement sensible à l’ordre des imports, et seule l’exportation par défaut de pino était instrumentée.
Même les variables locales au module ne se comportaient pas comme prévu, donc j’ai dû utiliser
globalThis.Et malgré ça, je suis quand même tombé sur https://github.com/vercel/next.js/issues/80445.
Au final, ça fonctionnait, mais la configuration était vraiment pénible.
C’était mon expérience avec un routeur manuel (= sans
@vercel/otel).Si la décision a bien été prise de prendre en charge un middleware côté serveur, je ne comprends pas pourquoi il n’y a toujours pas de chaîne de middlewares — plusieurs fonctions chaînées — et qu’un seul est pris en charge.
Tous les autres frameworks serveur proposent cette fonctionnalité.
J’ai du mal à croire que « ne pas pouvoir chaîner plusieurs middlewares » soit réel.
https://nextjs.org/docs/messages/nested-middleware
Dire qu’il faut fusionner plusieurs middlewares dans un seul fichier pour les exécuter, c’est difficile à croire.
Si je lis bien, Next.js soutient donc qu’il ne faut pas les structurer en plusieurs fichiers, mais tout fusionner dans un seul ?
C’est à cause de problèmes de scope qu’il est difficile d’utiliser plusieurs fichiers ? Pour un framework, c’est une exigence complètement absurde.
Je n’arrive pas à me débarrasser du soupçon que la plupart de ces décisions absurdes ne sont pas prises dans l’intérêt du framework, mais parce qu’elles arrangent davantage Vercel.
La première fois que j’ai vu Next.js, ça m’a immédiatement rappelé Meteor.js.
J’ai investi pas mal de temps pour l’apprendre dans un projet perso, mais avec son abstraction excessive et sa rigidité, c’était difficile d’aller au-delà du prototype.
Ce genre de solution « batteries incluses » continue de réapparaître, parce que la configuration est pratique.
Récemment encore, sur Hacker News, dans une comparaison Laravel vs Symphony, certains disaient que tout s’écroule quand la complexité augmente.
Comparée à une approche assemblée à la carte comme les anciennes SPA NodeJS/React, où chaque pièce est indépendante avec des abstractions de plus bas niveau, cette approche est plus flexible et permet de remplacer des morceaux plus facilement.
Il y a aussi des inconvénients, mais c’est plus fluide que l’overengineering, autrement dit la complexité empilée.
Je comprends très bien pourquoi les solutions batteries incluses sont populaires.
Assembler toutes sortes d’outils et de bibliothèques en garantissant leur compatibilité est vraiment pénible.
Ce type d’approche modulaire fonctionne mieux quand quelqu’un de plus expérimenté se charge du setup.
Je viens du monde asp.net, qui a mauvaise réputation dans certaines communautés de dev startup, mais c’est en réalité un framework extrêmement bien conçu.
C’est du batteries incluses, mais j’ai toujours pu sortir du cadre et surcharger ce que je voulais ; je n’ai jamais eu l’impression de me battre contre le framework.
Blazor Server et Blazor Webasm permettent tous les deux d’écrire le front en C#, et chacun est bien adapté à des panels internes ou des apps SaaS.
Et surtout, le rendu serveur traditionnel permet déjà de tout résoudre.
Je le recommanderais vraiment à quiconque est frustré par les frameworks web.
Aujourd’hui, le support cross-platform est bon, c’est rapide et assez facile à apprendre.
Il y a bien une courbe d’apprentissage, mais une fois la structure modulaire comprise, je pouvais surcharger ce que je voulais sans difficulté.
J’ai aussi très rarement rencontré des limites comparé à d’autres frameworks.
L’idée d’assembler chaque composant comme dans NodeJS/React SPA est assez étrangère à Angular.
Angular n’est pas une bibliothèque mais un framework, et il embarque la plupart des fonctionnalités nécessaires.
(RxJS a une petite courbe d’apprentissage, mais les bases suffisent déjà à le rendre très puissant.)
En général, j’ai rarement eu l’impression de me battre contre le framework dans une SPA Angular.
La documentation et les tutoriels, y compris Tour of Heroes, sont excellents.
https://v17.angular.io/tutorial/tour-of-heroes
La documentation la plus récente est disponible sur https://angular.dev/
Laravel est un exemple de réussite d’abstractions sur-ingéniérées.
Grâce à Laravel, je n’ai jamais regretté un choix en production.
Un peu hors sujet, mais relier en permanence toutes sortes de petits outils et bibliothèques qui ne sont pas tout à fait compatibles, c’est littéralement mon travail.
Notre équipe est petite, donc on passe énormément de temps à tout mettre à jour et à maintenir l’ensemble, avec en plus des problèmes fréquents dus à des packages abandonnés depuis longtemps.
En plus de l’expérience, le temps initial de mise en place et les coûts de maintenance sont bien plus élevés qu’on ne l’imagine.
Après l’avoir fait moi-même, j’ai eu le sentiment qu’avec Rails la productivité était dix fois supérieure au bricolage de bibliothèques en Node.
Les problèmes n’apparaissent que si on n’adhère pas au socle et à la philosophie du framework — par exemple si on déteste ActiveRecord.
Dire que « tout casse quand la complexité augmente », c’est surtout le signe d’un manque de compétence technique.
Je suis plutôt un grand défenseur de React, et j’ai aussi aimé le passage des class components aux hooks.
Mais chaque fois que j’utilise Next.js, je n’arrive plus à comprendre par où ça a commencé à dérailler.
J’aime beaucoup de frameworks et même des langages exotiques, mais Next.js est la seule expérience où je ne comprends même pas la moitié des messages d’erreur.
J’ai perdu un temps énorme sur des problèmes d’hydration particulièrement bizarres.
Je n’utilise ni React ni Next.js.
Personnellement, je préfère HTML+CSS avec un peu de JS vanilla.
J’ai déjà vu une simple landing page Next.js se casser dans Firefox.
Et le pire, c’est que l’échec prenait la forme d’un écran noir avec du texte blanc recouvrant tout le contenu, affichant seulement « An application client side error has occurred ».
J’ai été surpris qu’une simple landing page puisse même échouer à se rendre, puis quand j’ai compris que c’était à cause d’un framework front JS, je me suis juste dit : « bon, forcément ».
C’est peut-être acceptable pour ceux qui cherchent à convaincre les utilisateurs, mais pour les gens en dehors de l’industrie, ça peut être déroutant.
Je pense que Next a déjà cassé sa propre proposition de valeur.
Les boîtes passées par le cycle VC finissent toujours comme ça.
Pour moi, c’est inutilisable maintenant, et Vite est devenu l’option par défaut.
J’ai toujours préféré les solutions légères.
Le terme « middleware » dans Next.js est propice à la confusion.
En réalité, c’est une edge function légère exécutée avant que la requête n’atteigne l’application — pour vérifier des en-têtes, faire du routage, poser de simples garde-fous, etc.
Elle s’exécute dans le runtime edge, qui est un environnement séparé du serveur applicatif.
L’auteur semble lui aussi confondre edge et runtime serveur.
Au début, moi aussi j’avais du mal à voir la frontière, et comme tout tourne autour de JavaScript, la distinction est floue.
Je pense qu’il faut un modèle mental clair.
Reprocher sa complexité à Next.js, c’est un peu comme reprocher à une boîte à outils de contenir autre chose qu’un marteau.
Le problème, c’est que la complexité de Next.js est auto-infligée.
Le terme middleware a déjà un sens bien établi dans presque tous les frameworks.
En général, un middleware est une chaîne de fonctions appelées avant la requête dans le runtime, avec l’idée qu’elles s’exécutent dans le même processus.
Next.js, lui, les déploie sur edge et n’en autorise qu’un seul.
Dans la plupart des applications, on n’a pas besoin de capacités edge ; ça devrait être opt-in uniquement quand on en a besoin.
Si on reprend l’analogie de la boîte à outils, il faut ajouter uniquement les outils réellement nécessaires.
Le terme « middleware » ne devrait pas être utilisé dans ce contexte par Next.js.
Ce n’est pas seulement un mauvais usage, c’est un abus de terminologie.
Middleware a une définition ancienne et bien établie dans l’industrie des web apps, donc si ça désigne quelque chose de complètement différent, il ne fallait pas employer ce mot.
J’utilise l’app router de Next.js et j’en suis plutôt satisfait.
Comme il est très facile avec Next.js de passer du front au backend, beaucoup de gens ont l’impression que cette partie aussi est complètement abstraite.
En réalité, c’est un système très complexe, et cette complexité, il faut l’assumer soi-même.
Une forte complexité ne veut pas toujours dire lenteur ou baisse de productivité.
Un système où front et back sont séparés est souvent plus simple à manipuler, mais aussi plus pénible.
Même si on connaît React, Next.js donne vraiment l’impression de devoir tout réapprendre, et il y a beaucoup de choses qu’on ne peut comprendre qu’en les vivant directement.
Malgré tout, une fois un peu habitué, c’est un système très pratique qui permet de passer facilement du frontend au backend.
Beaucoup de gens ont downvoté mon commentaire, et j’aimerais savoir pourquoi.
J’ai toujours envie d’apprendre.
Au lieu de faire seulement de la négativité aveugle dans ce genre de discussion, j’aimerais qu’on débatte correctement.
J’ai enfin l’impression de voir un avis raisonnable.
Par exemple, confondre sans réfléchir les notions de package/module en Python avec celles de module en Go, puis se plaindre que Go est mauvais, ce serait la même chose.
Il faut un minimum de compréhension de base de la technologie qu’on utilise.
Depuis le passage de Next.js à l’app router, j’ai l’impression qu’ils ont confié l’amélioration d’une API express à des diplômés de bootcamp.
Même si l’API express a ses limites, elle reste une approche mature, en cohérence avec cette conception en poupées russes que tous les interfaces serveur — servlet, rack, plug, etc. — ont accumulée pendant des années.
Au-delà de cette API middleware médiocre, supprimer les paramètres de requête pour les remplacer par des fonctions globales comme
cookies()etheaders()a aussi été une décision étrange.J’imagine qu’il existe des contraintes de conception fondamentales cachées derrière tout ça, mais vu de l’extérieur, on a l’impression qu’ils ont jeté toutes les leçons du passé pour refaire exactement les mêmes erreurs.
Et si on ajoute à ça le support d’un runtime edge lowest common denominator, les limitations deviennent encore plus fortes.
J’essaie toujours d’utiliser des stacks variées sur les nouveaux projets.
J’ai utilisé express+react, angular, vue, next, nuxt, go, .net, node, php, aussi bien côté front que backend.
Dans la plupart des frameworks, je vois des avantages et des inconvénients, et j’y trouve même du plaisir à apprendre quelque chose de nouveau.
Next.js est la seule exception : en construisant une application assez grosse, j’ai eu du début à la fin l’impression que chaque détail était bizarre, lent, pénible ou absurdement conçu.
Je suis toujours en train d’en assurer la maintenance, et c’est la seule « chose » que je déteste vraiment.
On me dit que l’écosystème est correct et que c’est populaire, mais dans mon expérience réelle, c’était irrémédiablement négatif.
C’est étrange, mais c’est la réalité.
Quelqu’un connaît l’adresse postale de Vercel ?
L’an prochain, cette issue aura l’âge d’entrer à l’école primaire, alors j’aimerais envoyer à l’entreprise une carte du genre « bonne rentrée ! »
https://github.com/vercel/next.js/issues/10084
Ce qui est dit dans les avis Hacker News ci-dessous est tout à fait juste.
« Next.js comporte une énorme couche d’abstraction dont 99,9999 % des projets n’ont pas besoin ; et dans les rares cas où quelque chose comme ça est réellement nécessaire, je pense qu’il vaut mieux construire une solution sur mesure à partir de composants de plus bas niveau »
Une API inutilement et excessivement complexe, un produit instable et incomplet qu’on continue pourtant à promouvoir obstinément comme production ready, et une dépendance énorme à Vercel qui rend l’exploitation sérieuse difficile ailleurs que sur Vercel.