Quelle technologie choisir pour son site internet en 2020 ?

D’abord écrit en AngularJS puis en React avec un serveur express, notre site a migré, il y a quelques semaines, sur Next.js. Je ne vous en veux pas de ne pas l’avoir constaté même si le gain de performance est manifeste. Le Server Side Rendering (SSR), encore mis en doute par certains consultants SEO il y a quelques années, n’a plus rien à prouver aujourd’hui. Si des tentatives plus ou moins réussies de mixer PHP et framework JS ont émergé à l’époque, la question de la technologie à utiliser pour réaliser un site internet en 2020 est complètement ouverte.

Il y a quelques mois voire années, mon discours était que nous ne devions utiliser le JavaScript qu’en cas de besoin. C’était une époque où les scripts chargés par les navigateurs étaient de plus en plus lourds pour une expérience utilisateur à peine améliorée: avoir des transitions de pages, des rafraîchissements de blocs... Aussi je n’ai jamais vraiment adhéré aux solutions qui prônaient l’utilisation massive de framework JS pour faire des sites vitrines ou e-commerce, les hybrides PHP/JavaScript en fonction de ce qui était référençable ou non, la génération de site pseudo-statiques… En plus de forcer la connaissance de plusieurs langages, ces solutions obligeaient les développeurs à trouver des corrections à des problèmes qu’ils n’auraient jamais rencontrés autrement (faire coexister deux routeurs en fonction de la section du site visitée par exemple). Comme disait Desproges : "Vivre en couple c’est résoudre ensemble des problèmes qu’on n’aurait jamais eu tout seul".

Avec l’avènement et la facilité d’utilisation du SSR dans les frameworks JS modernes, et plus encore avec le gain de poids que permettent les évolutions du langage et des frameworks comme Svelte, mon discours a radicalement changé. A l'instar de ce que ferait une application PHP classique, le SSR vous permet de requêter une API et de calculer le rendu HTML directement depuis le serveur pour un temps de rendu identique, alors pourquoi s’en priver ?

Faut-il jeter le PHP pour autant ? Je ne pense pas. Aujourd’hui faire un site en Twig avec un peu de Javascript quand c’est nécessaire peut être une solution tout aussi viable que tout miser sur React. Le premier critère qui devrait guider votre choix, est la composition de vos équipes. Même si le PHP est en perte de vitesse face au rouleau compresseur qu’est l’environnement JS, si vos équipes sont composées de développeurs Symfony, est-il vraiment nécessaire de les former à un nouveau langage, un nouveau framework, de nouvelles méthodes ? Si deux technologies sont équivalentes pour vos besoins, votre principal souci devrait être que votre choix soit plébiscité par vos équipes. Un développeur heureux et un développeur qui ne râle pas...bon ok, c’est un développeur qui râle moins.

Si vous vous posez cette question c’est sans doute que vous connaissez notre expertise en Symfony, mais que vous ignorez que nous intervenons aussi sur les quatre grands frameworks qui agitent la communauté JS ces dernières années : React, Vue, Angular et récemment Svelte.

Premier élément de réponse : c’est votre serviteur qui a fait ces migrations successives. Même si j’ai 20 ans de développement PHP derrière moi, dans la mesure où je n’utilise pas Xdebug, je reste amateur, et mon expertise est plus portée sur le JavaScript. Pour la migration d’Angular.js vers React, je connaissais déjà Next.js mais il me semblait important de comprendre les mécanismes qui se cachaient derrière le SSR. En effet il est tout à fait possible de faire un serveur Express et de demander à React de renvoyer le rendu HTML d’une route spécifique. Dans la mesure où ce mode de rendu ne tient pas compte du cycle de vie des composants, vous devez gérer vous-même les requêtes à l’API, l’hydratation des composants avec les données récupérées, les différentes erreurs… Ça peut sans doute paraître effrayant, mais avec quelques astuces ça ne l’est pas tant que ça et ça m’a permis de désacraliser complètement ce qui était nécessaire au Server Side Rendering. 

Il y a peu, un ami me disait avec beaucoup de lassitude : “Pouah, déjà je dois découvrir React, mais en plus il faut apprendre Next”. Ce n’était pas la première fois que j’entendais ce genre de discours. La hype faite autour de Next/Nuxt/Sapper est telle que certains développeurs sont découragés d’avance. À dire vrai, Next.js c’est juste React + un routeur (très simple) + le préchargement de données (très simple) + du SSR (où il n’y a rien à faire donc très simple) + beaucoup de malice… Si vous savez déjà faire du React, vous avez seulement deux ou trois conventions à apprendre pour pouvoir bénéficier du SSR avec Next.js. Pour vous donner un ordre d’idée, le passage de la version React + Express à Next n’a pris qu’une poignée de jours.

Notre site devrait subir d’ici peu une évolution graphique, mais peut-être est-il temps d’aborder une révolution technologique ? Peut-être est-ce l’occasion de migrer vers un autre framework, de rendre le site toujours plus léger et l’expérience améliorée. Svelte/Sapper est mon sujet d’étude ces derniers temps alors pourquoi ne pas faire deux versions du nouveau site pour pouvoir les comparer ?

Ressources graphiques : Technology vector created by pikisuperstar - www.freepik.com