Dans [la partie précédente](/fr/blog/pourquoi-je-nexte-nextjs-1), je vous racontais comment suite à ma déception de NextJS 13 (dont les fonctionnalités étaient inutilisable à la sortie), je m'étais un peu éloigné du framework. Cependant... ![Cependant !](/images/blog/posts/fr/cependant-jdg.gif) ... j'ai décidé d'attendre **la version 14**. Sûrement, j'allais bénéficier de nouveautés, alors pourquoi pas ? En plus, comme l'an dernier, j'avais une petite mise à jour à faire sur mon site, et c'était le moment de migrer vers le routeur _app_. ## Après le choc, la réalisation Je migrais mes pages une par une, et puis soudain... je me prends **ma première erreur liée au conflit entres composants serveur/client**. Ce truc qui en a énervé plus depuis la version 13. Et j'ai soudain réalisé ce dont tout le monde s'était plaint l'année passée : il faut **réapprendre le framework**. Mais est-ce que j'ai **le temps** ? Pas vraiment, mais s'il le faut... Est-ce que j'en ai **envie** ? Franchement non. Et ceci pour trois raisons. ## Raison 1 : je n'en peux plus du code React Je suis sur React depuis 2018. J'ai vu arriver Fragment, les hooks, Context... J'ai évolué avec sur presque tous mes projets client, et sur la plupart de mes projets perso. Mais après avoir [découvert Svelte](/fr/blog/svelte-decouverte), et réalisé le temps que je perdais à écrire des lignes et des lignes pour rien... ```js // React export default function Component({ someProp }) { const [bool, setBool] = useState(false); return (

{someProp}

); } ``` ```js // Svelte

{someProp}

``` ... j'ai vraiment relégué React à _ce truc que je dois utiliser parce que c'est là depuis un moment et qu'on a trop investi dessus_. Mais pour moi, en voyant ce qui se faisait aujourd'hui, c'était une technologie vouée à **évoluer ou disparaître**. ## Raison 2 : la nouvelle direction de React (et NextJS) Et en effet, React a décidé d'évoluer. L'équipe React travaille avec Vercel/NextJS désormais, et l'outil prend une nouvelle direction pour faire quelque chose d'assez intéressant avec les **Server Components** en investissant le côté serveur... ... mais **je n'en ai pas grand-chose à faire**. 1. Dans les projets sur lesquels je travaille, React n'est que l'outil de **rendu côté client** qui permet à nos utilisateurs d'interagir avec le site. 2. Les projets qui sont assez complexes pour nécessiter son utilisation sont séparés en couches côté front et back, **fortement découplées**. 3. En fait, ces dernières années, j'ai passé le plus clair de mon temps à **découpler les logiques des fonctionnalités le plus possible de la couche React**. Entendez-moi bien : je vois très bien l'innovation et les possibilités. Mais **je n'utilise pas React pour ça**. ## Raison 3 : je n'ai plus confiance Vous savez ce qui me pousse vraiment à lâcher NextJS ? La rupture **brutale** avec la version 13. - On a dû **revoir toute notre codebase**. - Pour un truc qui ne fonctionnait pas **pendant des mois** (inadmissible, pourquoi ne pas attendre ?). - Et on a **perdu des fonctionnalités**. Personnellement, j'ai très mal digéré la **perte définitive de l'internationalisation**. La fonctionnalité a tout simplement disparu avec la migration vers _app_. > "Mais il existe des solutions pour ça." Oh, j'ai bien essayé une alternative utilisant le middleware Next qu'on nous proposait pour avoir les langues avec le routeur, mais [le code était juste imbuvable](https://locize.com/blog/next-app-dir-i18n/). Et si je dois le coder moi-même, **à quoi bon utiliser le framework** ? Et qu'est-ce qui m'attend ensuite ? Qu'est-ce que les devs vont décider de supprimer ? Pourquoi j'utilisais Next au fait ? > "J'ai donc adopté NextJS parce qu'il me **facilitait le travail**, que les projets étaient **simples à maintenir**, et les mises à jour **rapides** à effectuer." — Moi, en introduction de la partie 1 J'estime que ces conditions **ne sont plus réunies**. ## Est-ce que j'ai besoin de ré-apprendre NextJS ? En fait, en voyant la prise de tête qui m'attendait, le combat contre les erreurs console, et tout le reste, il est apparu que **j'aurais plus vite fait d'apprendre un nouveau framework**. Et ce serait sûrement **plus intéressant**. J'ai décidé de retenter un coup avec **SvelteKit**, l'équivalent de NextJS côté Svelte. Comme NextJS, SvelteKit : - utilise un **système de routage** similaire au dossier app de NextJS - me permet d'utiliser un **code plus clair, plus concis** - peut être **déployé sur Vercel** au même titre que NextJS (!) Les fonctionnalités dont j'ai besoin, **sans le boilerplate React**. Que demander de plus ? > "Mais Daniel, ça va te prendre un temps fou. Est-ce raisonnable de remplacer toute une codebase ?" En temps normal, non. Mais... ... ## Coup de théâtre ... Svelte est tellement facile d'accès qu'en bossant les soirs (pas tous) et les week-ends (idem), **j'ai réussi à refaire mon site sur SvelteKit en deux semaines**. Et en fait **vous êtes déjà sur la version SvelteKit.** > "Scélérat ! Tu nous as bien eus !" La migration n'a pas toujours été facile. Par exemple, SvelteKit ne gère pas non plus la **localisation** _de facto_, mais le code pour l'utiliser avec le routeur est bien plus concis et clair. Un autre détail qui m'a rendu fou est que SvelteKit **pré-charge les pages derrière les liens**, ce qui peut entraîner des effets assez bizarres quand on n'est pas au courant de ce comportement par défaut (désactivable). Mais rien d'insurmontable, et j'en ai aussi profité pour corriger quelques bugs qui traînaient sur la version précédente, et que j'avais complètement loupés, occupé à écrire des _useState_... ## NextJS, c'est fini ? Bien sûr que non. **Je ne jette pas NextJS**. C'est un outil qui fait son job. Si un client débarque avec une appli NextJS, je serai au rendez-vous. Mais dans l'état actuel des choses, ce ne sera plus ma solution pour des projets perso. **Bref, _j'ai nexté Next_.** (_J'ai honteusement piqué cette phrase à **Olivier Maréchal** sur un commentaire LinkedIn. Merci, j'avais vraiment besoin d'un titre._)

Blog

Articles récents