Déconstruisons les frameworks JavaScript pour mieux réinventer le web !

Mis à jour pour le MiXiT.

Bonjour à toutes et à tous !

Vous trouverez plus bas des ressources pour creuser encore plus sur ce que nous avons vu toutes et tous ensemble.

Si vous souhaitez garder contact, n’hésitez pas à m’ajouter sur LinkedIn !

https://www.linkedin.com/in/nirinarabeson/

Et si vous voulez tester le framework présenté durant le talk, voici la commande :

npm i nirina.js

Pourquoi tu ne parles pas de Server Side Rendering (SSR) ?

Car je déteste le Server Side Rendering !

Trois raisons principales :

Je ne vois pas quel problème le SSR résout qui n’est pas plus simplement résolu par le Static Site Generation (SSG)
Les pires bugs de production que j’ai pu rencontrer étaient liés à du SSR
Cela rend les architectures plus complexes

Le Server Side Rendering a été inventé pour résoudre un problème : comment améliorer le SEO et la performance, pour des pages extrêmement distribuées dans le monde entier. Il se trouve que le Static Site Generation avec des islands fait presque la même chose, mais pour bien moins cher, avec comme inconvénient un moins bon SEO. Mais avez-vous souvent besoin d’une infrastructure mondialement distribuée avec un SEO optimisé aux petits oignons ?

Pour les pires bugs en production : je ne veux plus débuguer des bugs d’hydratation (c’est quand le serveur et le client ne sont pas d’accord sur l’html obtenu), et je ne veux plus débuguer des problèmes de bugs en prod qui apparaissent parce qu’un coup c’est le client qui fait l’appel et un coup c’est le serveur qui fait l’appel vers… le backend.

Pour l’architecture, c’est lié au point précédent : c’est un peu étrange, surtout dans un grand groupe, de rajouter encore un serveur qui va plus ou moins faire passe plat vers d’autres serveurs. N’avons-nous pas trop de microservices déjà ? Est-ce qu’on veut vraiment rajouter un serveur pour faire ce que nginx fait déjà bien ? Faire du SSR multiplie par deux toutes les questions d’infra et d’architecture que l’on peut se poser… Alors qu’on pourrait juste garder les choses simples et faire un serveur frontend simple, et plusieurs backends techniques.

Pourquoi tu es contre écrire des `fetch`et des requêtes `axios` ?

Écrire un appel API est une source d’erreurs incroyable : c’est complexe d’écrire proprement une baseUrl, il faut connaître les endpoints à appeler, savoir le verbe HTTP à utiliser, ajouter les bons headers et “deviner” le format attendu par les endpoints (ou se prendre des 400 tout le long).

À la place, transformez vos contrats d’interface en du typage strict avec un générateur de client API. Par exemple, vous pouvez tester openapi-generator. Au lieu d’écrire manuellement vos requêtes web, vous les faites générer en un client API javascript à partir des contrats d’interface / fichiers swagger de vos serveurs backend. Je suis sûr que vos ingénieurs backend sont capables de faire cela.

Bonus : vous pourrez très facilement intégrer toutes les problématiques d’authentification ou de cache de façon unifiée grâce à ces clients APIs.

Avec quoi publierais-tu ton premier package ?

vite.js permet déjà avec le mode lib de publier de très bons packages. Et pour correctement définir les points d’entrée, exporter du CSS, exporter les bons modules, je vous invite à copier coller des packages que vous aimez bien, ou à utiliser une IA pour proprement mettre tout cela en place.

Je vous propose de lire la documentation de vite.js qui est plutôt pas mal : https://vite.dev/guide/build#library-mode

Quelques idées pour vos premiers packages :

Un client API généré à partir d’un swagger (voir le point précédent)
Un début de composants ou de styles réutilisables ?
Pourquoi pas vous lancer dans un design system ?
- J’ai un super talk sur les designs systems et l’indépendance aux frameworks par un très cher ami : https://www.youtube.com/live/rWqIEWStdkA?t=15064s

Tu parles de microfrontends, peux-tu en dire plus ?

L’idée d’un microfrontend, c’est de permettre de déployer des bouts d’une application indépendamment. On va un peu plus loin que la notion de packages parce qu’on inclue aussi la façon dont le package va être utilisé et déployé en production.

Techniquement, c’est un peu plus complexe que ça mais si vous voulez commencer, vous pouvez vous en sortir avec des iframes.

Fonctionnellement, une stratégie microfrontend est plutôt centrée sur la façon de délivrer vos applications web, surtout quand elles ont des cycles de livraisons différents. En fonction de l’organisation de votre équipe, cela peut très bien ou très mal se passer (un vrai cas d’école de la loi de Conway)

Utiliserais-tu ton propre framework pour partir en production ?

A priori, non.

Aujourd’hui je n’implémente quasi aucune notion de performance. Je pourrais le faire static site generate mais il ne serait je pense pas très efficace pour faire des injections stratégiques de réactivité… À tester.

Des liens qui m’inspirent

J’aimerais également partager une liste d’articles et de liens qui m’ont inspiré et permi de vous faire ce talk :

La meilleure explication écrite de comment faire de la réactivité, par la team de vuejs : https://vuejs.org/guide/extras/reactivity-in-depth.html
Une autre excellente explication en conférence par Estéban Soubiran : https://www.youtube.com/watch?v=3PcrqsBVGgA
Un excellent article qui lutte contre le “frameworkism” et cette idée que le web devient exclusivement du react https://infrequently.org/2024/11/if-not-react-then-what/
Un super talk deux bons amis sur comment React fait sa réactivité et surtout comment React l’optimise: https://www.youtube.com/watch?v=_edOnkr8Yy4&list=PLuZ_sYdawLiWenx-X315dfZNOaliVnSTY
Un super talk sur les designs systems et l’indépendance aux frameworks par un très cher ami : https://www.youtube.com/live/rWqIEWStdkA?t=15064s
Vous trouverez le graphique controversé de performance du web selon astro ici : https://astro.build/
Je vous invite à jeter un oeil sur le site de solidjs : https://www.solidjs.com/
L’article de svelte qui m’a donné envie d’explorer la réactivité sans arbre virtuel : https://svelte.dev/blog/virtual-dom-is-pure-overhead
À l’origine, la première version de ce talk était sur vue vapor, qui reprend les techniques de solidjs et svelte pour fonctionner sans DOM virtuel https://www.vuemastery.com/blog/the-future-of-vue-vapor-mode/

Merci beaucoup pour la lecture, et je vous souhaite une excellente journée !