Retours sur LyonJs 100

Pour célébrer leur 100ème événement, le meetup LyonJS a organisé une journée de conférences en mono-track, pour le plus grand plaisir des habitués ! Environ 150 personnes étaient présentes, confortablement installées dans une salle du cinéma de Lyon Part-Dieu réservée pour l'occasion.

Voici un résumé des notes prises lors de l'événement, en espérant que cela vous incitera à visionner les captations qui ne tarderont pas à arriver sur la chaîne YouTube du meetup. Les organisateurs sont toujours très rapides à ce sujet !

Astro, le framework Web JS multi page

Par Matthieu Lux

La présentation s'est déroulée en deux parties : d'abord, une introduction au framework Astro et ses concepts, suivie d'un retour d'expérience sur sa mise en place chez Proton.

Astro ne construit pas des single-page applications (SPA) mais des multi-page applications (MPA). Contrairement à Angular, React ou Vue.js, qui sont des SPA, Astro fonctionne différemment :

• Côté SPA :
  • Au chargement du site, beaucoup de JavaScript est embarqué (tout le site, sauf certains modules en lazy fetch).
  • La navigation se fait en JavaScript, ce qui permet un effet "whaou" avec un affichage constant entre les pages (le JS étant déjà chargé).
  • En contrepartie, le chargement initial est plus long et complexe.
• Côté Astro :
  • Le système de chargement initial est similaire à celui des SPA, mais l'objectif est de réduire au maximum le JS à charger et interpréter par le navigateur pour qu'il soit interactif.
  • Seul le JavaScript correspondant à la page est chargé, et la navigation est une vraie navigation côté navigateur, avec une page récupérée côté serveur à chaque fois.
  • Particulièrement utile pour du contenu marketing qui doit être bien indexé.

Fonctionnement d'Astro :

• Pages statiques construites au moment du build, rendues côté serveur avec possibilité de rendu côté client à certains endroits.
• Par défaut, une page Astro n'a pas de JS pour être le plus rapide possible.
• Système "d'island" pour permettre des composants plus complexes. Un site Astro peut accueillir des island de différentes technologies (React, Preact, Vue, Angular, etc.). Pour autant, bien cela n'empêche pas de se demander s'il est pertinent de mélanger !
  Voici comment Astro défini un island sa documentation : Islands architecture works by rendering the majority of your page to fast, static HTML with smaller “islands” of JavaScript added when interactivity or personalization is needed on the page.
• Server islands pour un rendu dynamique côté serveur.
• Client islands pour un rendu de composant dynamique côté navigateur.
• Fichiers templates en ".astro" composés d'une partie de code Node.js exécutée côté serveur, et d'une partie JSX pour le rendu serveur ou client selon le type d'îlot.
• Communication entre island possible, notamment avec la librairie Nanostore.
• Synergie avec Zod, sur lequel repose certaines fonctionnalités d'Astro.

Retour d'expérience chez Proton :

• Astro en production depuis 2 ans.
• Avant, Gatsby était utilisé, mais avec plusieurs douleurs :
  • Builds très longs dus à la génération statique de tout le site (20k pages, plusieurs Go d'images).
  • Déploiements compliqués nécessitant plusieurs personnes.
  • Chaque modification du site (notamment du blog) demandait un redéploiement complet.
  • Mauvaise expérience avec le GraphQL (à la sauce Gatsby?).
• Transition vers Astro :
  • Contenu marketing généré statiquement.
  • Partie blog générée dynamiquement avec plusieurs niveaux de cache.
  • Images mises dans Cloudflare (auparavant embarquées dans la génération Gatsby).
  • Passage en mono-repo avec Turborepo.

Tester c'est tricher

Par Jules Poissonnet & Antoine Caron

Le ton du talk est donné dès le début : Antoine se balade avec un parapluie en intérieur, et Jules lui demande pourquoi. Réponse : "Pour ne pas être mouillé !"

Quatre profils types de développeurs face aux tests sont identifiés :

• Les believers, qui ne font pas vraiment de tests automatiques, surtout des tests manuels.
• Les technophiles, qui font des tests parce qu'il faut en faire, mais tombent facilement dans le piège de se concentrer plus sur l'outil que sur la stratégie de test, quitte à faire des tests inutiles.
• Les sceptiques, qui visent un coverage de 100%, quoi que cela veuille dire.
• Les good enough, qui ne testent que ce qu'ils jugent important, mais dont la démarche n'est souvent claire que dans leur esprit.

Bref, quel que soit la stratégie de tests adoptée par nos différents profils (forme divers de pyramides, diamant, ice cream, autre), l'objectif est de dépasser les dogmes et de se demander pourquoi on teste, et si c'est toujours pertinent de mettre en place tout un système pour quelque chose qui est peu coûteux en temps sans test.

Motivations pour écrire des tests :

• Stabilité : tests de non-régression.
• Intégrité : confiance en l'application lorsque la CI est verte.
• Vérification de la conformité : l'application fait bien ce qui est attendu.
• Documentation.
• Reproductibilité : notamment pour les edge cases.

Conseils donnés :

• Vitest est la librairie à préférer pour les tests unitaires : rapide et simple à mettre en place.
• Playwright est un excellent candidat pour les tests e2e.
• Privilégier les sélecteurs accessibles (type getByTitle, getByRole, etc.) pour des tests plus résilients.
• Mocker les appels réseau pour gagner du temps sur l'exécution des tests (attendre la réponse d’une API peut faire perdre beaucoup de temps en cumulé) et tester les edge cases.
• Mutation testing pour un score de coverage à la fois quantitatif et qualitatif.
• Créer un testing.md pour expliquer les stratégies de tests, en reprenant les différents motivateurs et en expliquant comment les résoudre.

How to build a video editor in React

Par Jonny Burger

Une démo de 30 minutes de l'outil Remotion par son créateur venu de Suisse. Remotion permet de créer des vidéos programmatiquement en React avec des layers, du sous-titrage avec différents styles, etc. Le rendu est sympa et les fonctionnalités nombreuses.

Avec l'intégration de l'IA, Jonny a montré comment ajouter un logo LyonJS sur une vidéo, envoyer la vidéo à une IA pour obtenir un transcript, et l'intégrer à la vidéo avec un style "TikTok", le tout en très peu de temps !

Savez-vous vraiment ce qu’est la couleur ? Découvrez la science derrière les pixels 🎨

Par Julien Sulpis, les illustrations proviennent de sa présentation

Le titre de ce talk ne me donnait pas spécialement envie, mais Julien en était conscient et a joué dessus. Heureusement, la conférence étant en mono-track, j'ai été forcé d'assister à son talk !

Julien a posé deux questions dès le début pour susciter l'intérêt :

• Pourquoi, à luminosité égale, une couleur paraît-elle plus claire qu'une autre ? Question importante pour le contraste et la lisibilité d'un texte (accessibilité).
• Comment se fait-il que mon CSS ne rende pas la même couleur que sur la maquette Figma pour un même code RGB ? Et ce n'est pas un effet d'optique, la pipette du Mac le confirme !

Cette accroche faite, on repart sur des bases de la physique : la couleur c’est la perception de différentes longueurs d’onde.
Certaines couleurs prennent plus de place que d’autres sur ce spectre et celles à la frontière du visible (rouge et bleu) nous paraissent plus sombres.

Il a cependant fallu réussir à représenter les couleurs de manière mathématique (puis informatique) afin de clairement les définir !
Plusieurs modèles et espaces de couleurs se sont enchaînés et sont encore utilisés selon les situations.
Celui que l’on utilise couramment est l’espace de couleurs sRGB avec le modèle RGB (combinaison rouge - vert - bleu de 0 à 255).
Il existe également d'autres manières de représenter un code couleur comme les modèles HSB ou HSL qui partent d’une teinte (“Hue”) et font varier la “saturation” ainsi que la clarté (“Lightness”) ou la luminosité (“Brightness”).

Cependant, depuis les années 2010s, nous avons de meilleurs écrans, notamment côté Mac ces derniers affichent un espace de couleur plus important que sRGB : le P3 !

Ces affichages sont donc capables d’afficher plus de couleurs et selon ce que vous utilisez vous travaillerez dans un espace de couleur ou l’autre : dans notre cas initial, Figma est configuré dans l’espace de couleur p3 (c’est réglable, allez vérifier votre configuration !) tandis que par défaut CSS est dans l’espace sRGB.
Il est possible d’écrire du CSS pour avoir des couleurs en P3 et des media queries existent pour savoir si l’écran le supporte ou non.

Reste la 1ere problématique : comment se fait-il qu’à luminosité égale une couleur peut nous paraître plus claire qu’une autre ?
Entre en scène un nouveau concept : la luminance qui correspond à “la sensation visuelle de luminosité”.
On voit notamment que sur notre dernière image, certaines couleurs sont compressées dans l’espace (bleu, rouge, jaune) tandis que d’autre prennent une grande place (vert).
Les mathématiciens se sont longuement penchés sur ce sujet et en 2020 on a eu une grande avancée avec des modèles proposant des corrections : OKLAB et OKLCH qui permettent de faire des gradients et palettes plus corrects.
Il est possible de spécifier ces modèles lorsque l’on fait nos gradients en CSS ou via l’utilisation de libs.

Crafter de meilleures UI, en pensant le DOM comme une API

Par Manon Carbonnel

Manon commence par nous partager son constat : beaucoup de développeurs n’aiment pas le CSS car ils ne savent pas l’organiser et on se retrouve facilement avec un “fichier projet” à plusieurs dizaines de milliers de lignes, avec des règles qui se contredisent et où il sera donc très compliqué de savoir ce que l’on peut faire sans provoquer d’effet de bord.

La solution ? Bien organiser son CSS en plusieurs fichiers. Soit en atomic design avec un dossier pour le CSS des atomes (les briques UI les plus petites de l’application), un autre pour les molécules et un dernier pour les organismes.
Autre possibilité, si vous utilisez un framework CSS (type bootstrap), utilisez la même organisation que ce dernier pour les surcharges de styles.
Dans les 2 cas, le but est de faciliter la recherche des styles et bien appréhender les conséquences d’une modification.

Un petit rappel sur le fait que la priorité d’application des règles CSS se fait avec un calcul de score de spécificité en fonction des sélecteurs que l’on met : 100 points pour un id, 10 points par classe/attribut, 1 point par élément (plus de détails). A score égal, c’est la règle écrite en dernière qui prend le pas.

Quelques conseils d’outils pour faire des tests de non régression visuel : Loki (outil ligne de commande) et Chromatic (Saas). Les 2 outils ont une forte synergie avec Storybook et Manon avait fait un article pour les présenter.

On parle ensuite accessibilité et du mauvais goût qu’ont les “div soup”. Avec HTML5 de nombreux éléments existent, avec un sens sémantique et il convient de les utiliser autant que possible. Il existe un diagramme d’aide à la décision :

Enfin, une recommandation pour l’outil Axe qui est un outil de test pour l’accessibilité qui s’intègre dans une CI et est également disponible en tant qu’extension.

Deno, l'avenir du dev JS/TS ?

Par Jérémie Patonnier

Jérémie commence par un peu d’historique :

• 2009 Ryan Dahl présente NodeJs à la JSConf
• 2018 Ryan Dahl revient à la JSConf pour s’excuser de ses erreurs sur NodeJs et présenter Deno qui corrige notamment
  • L’absence initial des promesses avec un fonctionnement asynchrone basé sur les callbacks
  • Le process de build avec un V8 qui n'est maintenant utilisé que par NodeJs
  • Pas de sandbox sécurisée : Node tourne avec la possibilité de tout faire sur la machine
  • Une gestion des dépendances centralisée avec NPM
• 2020 sort la V1 de Deno mais ça reste assez instable, on peut avoir de gros changements d’une mineure à l’autre
• 2024 sort la V2 de Deno qui s’annonce comme étant prod ready et avec support de Node et NPM ( 😮!)

Mais pourquoi s’intéresser à Deno ?

Voilà une liste de features Game Changer

• Deno tourne dans une sandbox sécurisée
  • Il faut passer des flags explicites pour donner des autorisations qui peuvent être très précises (droit de lecture dans un dossier, utilisation du réseau…)
  • Vise plus l’utilisation en local que sur un serveur où une utilisation de docker apporte normalement déjà un certain cadre
• Typescript est proposé nativement et par défaut
• On peut écrire du JS avec de la JSdoc et avoir une vérification du typage
• Modules en ESM, exit le commonJS ! (on peut toutefois en importer)
• Le système de module est décentralisé et on a un cache local global “à la PNPM mais en mieux”
• Transition simple depuis NodeJs
  • Deno comprend le package.json et réussit à bosser avec
  • Il faut juste faire attention à ce que toutes les dépendances venant de Node soit préfixées par “node:”, ce qui est déjà préconisé côté Node
• JSR, un package registry nouvelle génération
  • Agnostique runtime (Deno, Bun, Node…)
  • Utilisable avec les autres packages manager (NPM, yarn…)
  • Typescript friendly : ce sont les sources qui sont publiées (et non un build). Les sources sont donc directement utilisées par les runtimes intéressés (Deno) et sinon un build est fourni
  • Attention tout de même, c’est très récent donc les projets qui s’y trouvent manque probablement encore de maturité
• Linter prêt à l’emploi
  • Pour le moment un peu moins de règles disponibles qu’eslint, qui reste disponible sous Deno si besoin
  • Prettier devient inutile
• Runtime de test prêt à l’emploi
  • Assez complet, rend déjà inutile un certain nombre de librairies
  • Partie mock pas encore totalement au point, ce qui peut laisser vitest légitime pour certains cas
  • Jest à bannir dans tous les cas car pas super efficace avec les ESM
  • Disponible sur JSR donc utilisable hors Deno
• Possibilité de créer facilement des exécutables standalone pour une exécution en ligne de commande (pas de possibilité de remplacer un electron par exemple)

En bref, un talk très enthousiaste de la 2ème version de Deno et qui est préféré à Bun qui est vu comme moins avancé que Deno mais surtout qui n’a pas corrigé le problème d’un système de module centralisé à la NPM qui est l'une des plus grosses critiques faites à Node.

Tout sur les composants serveur Nuxt

Par Julien Huang

Le passage après le talk sur Astro n'a malheureusement pas été en faveur de ce dernier talk, qui s'est révélé peut-être un peu compliqué pour les personnes moins averties sur l'écosystème Nuxt !

Présentation des Nuxt Island qui est le concept un peu inverse de ce qu’on a côté Astro : Nuxt donne une page intéractive par défaut avec la possibilité de créer des islands qui sont des composants sans interactivité.

Conclusion de la journée

C'était un super événement offert par les organisateurs, speakers et sponsors. Un grand merci à eux ! Nous avons été gâtés à tous les niveaux : speakers, confort du lieu, nourriture, et une ambiance conviviale. Bref, une superbe journée.

Ce que je retiens personnellement :

• Astro est un choix intéressant pour un site avec du contenu statique ou marketing.
• L'idée du "testing.md" pour expliquer les stratégies de tests.
• Remotion comme outil intéressant pour l'automation marketing.
• Faire attention au profil de couleur utilisé dans Figma et peut-être abandonner la notation RGB au profit d'une autre.
• JSR : un package registry à étudier.

Le talk que j'ai préféré est celui sur la couleur, dont je recommande de regarder la captation lorsqu'elle sera disponible.