Recapt Octobre 2022

Les nouveautés et nouvelles qu'il ne fallait pas manquer sur l'écosystème React / Javascript, d'Octobre 2022 🤗

Au programme ce mois-ci :

• NextJS 13 et son lot de nouveautés !
• Plusieurs annonces côté NodeJS
• Gatsby v5-alpha
• Les avantages / inconvénients du CSS-in-JS
• Les outils / packages à surveiller
• WTF JS?

NextJS 13 et son lot de nouveautés

NextJS est passé en version 13, et avec lui son lot de nouveautés. On notera notamment :

• Le dossier app/ qui sort d'alpha pour passer en beta. Pour rappel, ce nouveau dossier utilisé pour le file-routing, active par défaut les React Server Components, ainsi que la possibilité d'avoir nativement des Layouts dans Next. Le Data-Fetching a également été repensé, pour remplacer getStaticProps & getServerSideProps par un simple await fetch.
• next/image est maintenant stable et permet de tirer parti des fonctionnalités de lazy-loading natives des navigateurs.
• next/link qui permet -enfin- de se passer de rajouter un tag <a> en tant qu'enfant de <Link>
• Turbopack (alpha). Après avoir abandonné Babel et Terser, Next passe désormais à une solution 100% basée sur Rust et abandonne Webpack. D'après leurs premiers benchmarks, Turbopack est 10x plus rapide que Vite (!) et... 700x plus rapide que Webpack ! Le démarrage de l'app est également 4x plus rapide qu'avec Webpack. Turbopack a également un support natif des Servers Components, de Typescript, JSX, CSS,... Cependant, n'étant qu'en version alpha, vous ne pouvez utiliser Turbopack que pour le développement pour le moment, et non pour le build. Pour démarrer l'environnement de dev sous turbopack, utilisez simplement next dev --turbo

Vous pouvez découvrir le release note en entier, ainsi qu'un focus sur Turbopack

Avec toutes ces améliorations, j'en suis venu à me demander s'il ne serait pas intéressant de développer tout nouveau projet React directement avec Next, et d'abandonner CRA. En effet Next apporte un cadre et une rapidité de développement, notamment sur tout le routing, qui peut être assez lourd avec CRA et un react-router, alors qu'un simple file-system s'occupe de tout le routing pour nous côté NextJS. Sans compter les performances de caching / performance avec le SSR / ISR.

La société Causal a décidé de franchir le pas et d'abandonner CRA pour passer sur NextJS pour leur application. Il y a évidemment eu des problématiques, notamment sur le hosting (CRA n'a besoin que d'un serveur qui sert des statics, alors que Next a besoin d'un serveur Node qui tourne). La finalité est qu'ils ont amélioré les temps de chargement de 70% en passant sur NextJS. Vous pouvez lire leur article detaillé ici

Pour ma part je n'ai pas -encore- d'avis tranché sur la question, mais vu la quantité d'améliorations et l'adoption extrêmement rapide des toutes les RFC React de la part de Vercel/Next, à comparer avec la relative "lenteur" de CRA et react-script (le passage sur Webpack 5 étant toujours un désastre selon moi), envisager Next pour un nouveau projet à la plac de CRA doit être une option à sérieusement prendre en considération

Les annonces côté NodeJS

Avec tous les challengers à Node qui poussent, Node était obligé de réagir ! Le voici qui passe en version 19, timides améliorations, mais on notera les 2 nouvelles options --watch & --watch-path pour écouter tous changements dans un ficher/folder, et recharger le serveur (et venir donc en replacement d'un nodemon) Ces flags sont toujours en experimental. Le release note complet

Gatsby v5-alpha

Gatsby n'est pas en reste et annonce également sa v5 en alpha. Gatsby introduit donc la Partial Hydration pour n'envoyer au navigateur que le JS ayant besoin d'être exécuté, et leur Slices API qui va venir améliorer leur Incremental Builds.

En effet, Gatsby était capable de recompiler à la volée des pages, mais lorsque vous changiez un élément dans le header/menu ou footer par exemple, toutes les pages avaient besoin d'être recompilées. Leur Slice API va permettre d'isoler ces composants qui sont fortement partagés pour permettre de ne recompiler que les fichiers propres à ces éléments. Gatsby annonce une réduction du temps de compilation jusqu'à 90% pour ces cas.

Retrouvez le release note par ici

Avantages / Inconvénients du CSS-in-JS

Sam Magura, 2ème plus actif mainteneur de Emotion dresse un portrait sur les avantages / inconvénients du CSS-in-JS.

The Good

• Les styles sont "scopés localement". Aucun risque d'avoir vos styles CSS qui s'écrasent entre composants
• Avoir le CSS et le JSX au même endroit est plus facile pour la lisibilité. L'idée étant que dans la plupart des cas vous avez vos composants dans /components et vos css dans /styles et vous passez votre temps à faire des allers/retours entre ces dossiers
• Vous pouvez intégrer des variables JS directement dans votre CSS

The Bad

• CSS-in-JS ajoute de la complexité au runtime. Vos styles CSS sont définis au runtime, ce qui demande des cycles de CPU côté client supplémentaires
• CSS-in-JS augmente la taille du bundle. Le CSS étant directement dans le JS, la taille du bundle JS est donc forcément plus élevé
• CSS-in-JS est un cauchemar lorsqu'on utilise le SSR

Il détaille ensuite, benchmark à l'appui, les contre-performances de CSS-in-JS dans les performances au runtime. Au final sa société Spot a fait le choix d'abandonner CS-in-JS au profit des sass modules, natifs à React, qui permettent maintenant de faire du scope local, sans surcharger le runtime (les scopes étant définis au build)

Un très bon article que je vous invite à découvrir en intégralité

Les outils / packages à surveiller

• js13kgames Pas vraiment un "outils" mais le résultat du challenge de créer un jeu avec maximum 13kb de JS. Les résultats sont assez bluffant
• Bao.js Je vous parlais du runtime Bun.sh dernièrement qui vient bousculer NodeJS. Voilà un framework basé sur Bun pour remplacer Express, avec la même syntaxe, et annoncé 3.7x plus rapide que Express
• PrimeReact un UI Kit React open-source entièrement configurable et themable
• Vercel OG Images Vercel publie une librairie pour générer rapidement les og:images pour les réseaux sociaux. Cette lib transforme l'HTML/CSS en images. Il peut bien évidemment être intégré à NextJS.

WTF JS?

Que va afficher ce console.log ?

console.log( 1 + 2 + '3' + 4 * '5' )

Afficher la solution et les explications !

😱 '3320' 🤔

Alors pourquoi ? Ce ~nombre~ string semble tout droit sorti de valeurs aléatoires, et pourtant ! Tout d'abord, les priorités des opérateurs s'appliquent en JS, nous avons 1 + 2 + '3' + (4 * '5') et allons donc exécuter en premier la multiplication. Le signe * ne pouvant désigner qu'une multiplication, donc une opération mathématique, JS s'attend à trouver 2 nombres pour effectuer son opération, et si ce n'est pas le cas, vous avez l'habitude, il transtype ! Donc le '5' est transtypé en nombre 5 et on effectue la multiplication 4 * 5 = 20

Nous avons donc ensuite l'opération 1 + 2 + '3' + 20. Aucune surprise sur le 1 + 2 = 3, donc 3 + '3' + 20.

Le signe + en JS désigne soit une opération mathématique (l'addition) soit une concaténation de string. Si les 2 opérandes sont des nombres, JS effectuera une addition, sinon il effectuera une concaténation, en transtypant en string les éventuelles opérandes qui ne seraient pas des strings.

Nous aurons donc l'opération String(3) + '3' ce qui donne '3' + '3' = '33'. Nous nous retrouvons avec '33' + 20 qui tombe dans le même cas de figure que précédemment, donc '33' + String(20) => '33' + '20' => 3320 CQFD !

Ne manquez pas un article !

Envie de recevoir par email mes derniers articles et Recapt ?

Essayez de taper register <votre adresse email> dans la console 🎉