Dans la partie précédente, 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...
... 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, et réalisé le temps que je perdais à écrire des lignes et des lignes pour rien...
// React
export default function Component({ someProp }) {
const [bool, setBool] = useState(false);
return (
<div className={`some-class ${someBool ? "special-class": ""}`}>
{someProp}
<button onClick={() => setBool(!bool)}>Change</button>
</div>
);
}
// Svelte
<script>
export let someProp;
let bool = false;
</script>
<div class="some-class" class:special="{someClassProp}">
{someProp}
<button on:click="{() => bool = !bool}">Change</button>
</div>
... 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.
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.
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.
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.
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.)
