Pourquoi je n’aime pas Next.js (et pourquoi ce n’est pas si grave)

#Symfony #PHP #Javascript #Next.js #React.js

J’ai essayé Next.js, j’ai même insisté pour l’utiliser sur quelques projets… mais plus le temps passe, plus je me rends compte que ce n’est pas un framework qui me correspond. Ce n’est pas que l’outil soit mauvais - loin de là - mais il y a plusieurs points qui me dérangent, et que j’ai envie de partager. Peut-être que tu t’y reconnaîtras, peut-être pas. L’idée n’est pas de lancer une guerre de framework, mais plutôt d’ouvrir la discussion.
Bon c'est vrai que je suis un développeur plutôt Back...

Next.js et Vercel : une dépendance qui me gêne
Impossible de parler de Next sans évoquer Vercel. Tout est pensé pour que le déploiement se fasse chez eux, de façon fluide et “magique”. Et ça marche, c’est vrai. Mais derrière cette simplicité se cache une réalité : beaucoup de devs finissent prisonniers de Vercel, sans même s’en rendre compte.
Oui, on peut très bien héberger son projet Next sur un VPS ou un serveur dédié. Je l’ai fait, et ça marche. Mais il faut savoir bidouiller, configurer, comprendre ce qui se passe sous le capot. Autrement dit, on est vite tenté de rester dans l’écosystème Vercel… et ça, pour moi, c’est une forme de dépendance qui enlève un peu de liberté au développeur.

L’authentification : pourquoi faire simple quand on peut compliquer ?
Je ne comprends pas pourquoi un framework aussi populaire que Next n’intègre toujours pas de solution native pour gérer l’authentification. C’est un besoin basique dans 90 % des projets, et pourtant, il faut rajouter NextAuth, BetterAuth ou bricoler avec du JWT. Alors oui, ça fonctionne, mais ça ajoute encore des couches de dépendances externes. Quand je compare avec un framework comme Symfony ou Laravel, où l’auth est intégrée de façon claire et robuste, j’avoue que je reste un peu frustré.

Les performances : pas si bluffantes que ça
On entend souvent dire que Next.js, c’est l’avenir de la performance web, avec son SSR, son SSG et ses pages qui se régénèrent intelligemment. Sur le papier, c’est séduisant. Dans la pratique… c’est un peu moins impressionnant.
J’ai vu des applis Next tourner correctement, mais j’ai aussi vu des projets qui finissaient par charger énormément côté client. La fameuse hydratation de React, ce n’est pas gratuit : le serveur bosse, puis le navigateur rebosse derrière. Résultat, sur certains projets, on se retrouve avec un rendu qui n’est pas plus rapide - voire moins efficace - que ce que j’obtiens avec un bon vieux Symfony bien optimisé.

La complexité qui monte, qui monte…
Next.js se voulait au départ une simplification de React. Et c’était vrai, dans les premières versions : un peu de SSR, une organisation claire, et c’était parti. Mais au fil des mises à jour, c’est devenu une sorte de monstre hybride : App Router, middleware, conventions strictes, edge functions… J’ai l’impression qu’à chaque projet, il faut réapprendre une partie du framework. C’est peut-être une force pour certains, mais personnellement, je préfère un cadre plus stable et prévisible.

Le syndrome du framework “couteau suisse”
Next.js veut tout faire : du site statique, de l’application fullstack, des APIs, du rendu côté serveur, du rendu côté client… Et c’est là, à mon sens, que le bât blesse. Quand un framework veut être partout, il perd en simplicité et en lisibilité.
Je préfère choisir un outil adapté à mon besoin : Astro pour un site statique, Symfony pour une application métier, React pur pour une SPA. Next.js, à force de vouloir couvrir tous les terrains, finit par s’alourdir.... ou carrément Wordpress pour un blog.

Alors, Next.js, on jette tout ?
Non, bien sûr. Next reste un framework puissant, qui a fait bouger les lignes et qui a poussé l’écosystème React dans la bonne direction. Il a popularisé des concepts intéressants, comme l’ISR ou les edge functions. Et c’est une bonne chose !
Mais il ne faut pas tomber dans le piège de croire que Next.js est indispensable, ou qu’il est la seule voie à suivre. Il existe plein d’alternatives selon les besoins :

• Un blog statique ? → Wordpress (!)
• Une application complexe ? → Symfony
• Une interface riche mais sans backend ? → React ou Vue.
  
  

Next.js a des qualités indéniables, mais aussi des défauts qui, personnellement, me pèsent.
Et ce n’est pas grave : chaque outil a ses limites. L’essentiel, c’est de garder du recul, de ne pas suivre la hype les yeux fermés, et de choisir sa stack en fonction du projet - pas parce que “tout le monde le fait”.
Qui sait ? Peut-être que les frameworks de demain prendront le meilleur de Next.js tout en corrigeant ses travers. En attendant, je continue à explorer, tester, et surtout… à coder avec les outils qui me rendent vraiment productif.