#1 - NPM Package, PlayWright, Google LightHouse : retour de la Vue.js Amsterdam 2023

Pour la première fois, Wanadev s’est rendu à la plus grosse conférence annuelle autour de Vue.js : la Vue.js Amsterdam 2023. J’ai eu l’honneur d’assister à la 5ème édition, couronnée par le retour d’Evan You, le créateur de Vue.js et Vite, en personne.

Dans cette série de quatre articles, je vais vous faire revivre ces deux jours de conférences. En les lisant, vous aurez l’impression d’y avoir assisté !

Cet article est le premier des quatre, vous pourrez retrouver chaque partie de cette série ici :

• Partie 1
• Partie 2
• Partie 3
• Partie 4

Dans cet article, nous allons parler de Rock’n Roll, voir comment créer son package NPM, découvrir PlayWright pour tester ses applications de bout en bout, parler de commerce international, déconstruire les idées reçues sur Google Lighthouse et aborder le sujet de la performance sous Vue.js.

Beaucoup de sujets à traiter, alors c’est parti !

Comment faire du rock avec Vue.js ? Tim Benniks (Replay)

La Vue.js Amsterdam a débuté fort avec Tim qui joue des solos de guitare sur scène. Tout d’abord, on vote sur son application pour la musique qu’on souhaite le voir jouer, puis il joue en live sur scène.

Par exemple ici avec Enter Sandman de Metallica : https://youtu.be/LFUTEXOW2oo

Tim nous explique ensuite que, pour gérer le système de vote, il a utilisé supabase une alternative open-source à firebase. Il s’est aussi appuyé sur la librairie webmidi.js pour connecter sa guitare à son application. En effet, selon les passages dans la musique, les effets appliqués sur l’ampli sont différents.

Comment publier un package NPM ? Bjorn Lu (Replay)

Après une première présentation originale, Bjorn Lu, membre de la core team de Vite, nous fait un guide pour packager sa librairie. On se met dans la peau de Bob qui souhaite faire une librairie de mathématiques. Pour commencer avec les modules ESM, on doit toucher au fichier package.json. En voulant ajouter du TypeScript, on doit ajouter un fichier tsconfig.json. Pour fonctionner avec les anciennes versions de Node, il faut également penser à supporter CommonJS. Cependant, on peut décider quelles versions de Node.js ou du Browser on souhaite supporter en le spécifiant dans le fichier package.json.

On y découvre aussi comment gérer les points d'entrées multiples de sa librairie.

Il faut aussi pouvoir gérer les fichiers spéciaux :

Ensuite, Bjorn nous donne quelques conseils pour simplifier ce processus complexe de création d'une librairie :

• utiliser la JSDoc plutôt que TypeScript : adieu les fichiers avec les extensions .d.ts, plus besoin de la phase de transpilation, c’est plus facile à débugger et la vérification sur le type est conservée.
• supprimer CommonJS si possible (si la compatibilité avec les anciennes versions de Node.js n’est pas nécessaire).
• exporter en brut son package : typescript, vue, etc. dans le cas d'un usage privé et dont on est le seul consommateur.

Il finira par nous présenter les éléments importants à gérer dans le package.json, que vous pouvez retrouver dans la documentation

Enfin, il nous partage son outil publint qui fonctionne avec les packages npm mais aussi locaux. Cet outil permet de prévenir la plupart des erreurs liées à la création d’un package !

Comment faire de bons tests avec PlayWright ? Debbie O’Brien (Replay)

PlayWright est un framework de test développé par Microsoft qui permet de faire des tests de bout en bout (end-to-end).

Sa promesse :

• tous les navigateurs
• toutes les plateformes
• une seule API
• fonctionnement de façon complètement isolée
• exécution rapide

Derrière les tests, il est important d'avoir une philosophie de test pour ne pas se retrouver à tester des choses inutiles. Pour cela, il faut :

• tester ce qui est visible de l'utilisateur : on ne teste pas les noms des fonctions, les classes CSS, etc.
• garder les tests les plus isolés possible.
• écrire moins de tests, mais des tests plus longs.
• éviter de tester les dépendances.

Quelques bonnes pratiques de test :

• utiliser les locators (attend automatiquement que l’élément soit récupéré dans le DOM et réessaye tout seul s’il y a une erreur).
• utiliser le chaînage et les filtres.
• préférer les attributs utilisateurs plutôt que XPath ou les sélecteurs CSS.
• generator locators
• utiliser les assertions : cf. photo
• débugger en direct
• débugger dans la CI grâce au trace viewer
• tester tous les navigateurs (s'il n'existe pas sur votre OS, PlayWright l'installera !)
• garder ses dépendances PlayWright à jour
• utiliser le parallélisme et le sharding
• lancer les tests dans la CI

Comment Vue fait tourner le commerce international ? Mariam Reba Alexander (Replay)

Chez Maersk, société de transport international de conteneurs, on utilise Vue.js pour automatiser tous les processus le long de la chaîne logistique. Avec 4 millions de dollars de conteneurs commandés via leur application par heure, quand il a fallu migrer l'application de Backbone.js à Vue.js, c'était une opération délicate, mais les bénéfices ont été énormes. Le temps de chargement est passé de 7,4s à 2,5s en moyenne.

Ils ont aussi profité de cette refonte pour faire un gros travail d'uniformisation de leurs interfaces, en introduisant un design system et en se conformant aux standards de la communauté.

Ils ont aussi introduit Nuxt dans leur projet pour améliorer les performances grâce au rendu serveur :

Au fur et à mesure, ils se sont confrontés à un problème avec leur design system : comment le rendre résistant au changement, comment accepter un nouveau framework ? Ils ont donc décidé de partir sur des web components avec Lit pour encapsuler leurs composants Vue.js.

Pour Nuxt, ils ont utilisé ce plugin Nuxt pour faire des web components côté serveur.

Un autre gros chantier qu'ils ont entrepris a été, comme beaucoup, la migration de Vue 2 vers Vue 3.

Les idées reçues sur Google Lighthouse - Filip Rakowski (Replay)

Vous connaissez Lighthouse l'outil de Google pour mesurer le score de performance de votre application ? Filip Rakowki démonte dans sa présentation beaucoup d'idées reçues autour de cet outil et nous met en garde. Il ne faut pas prendre ce résultat pour argent comptant.

Tout d'abord, on nous rappelle que la performance a un impact direct sur la rentabilité du business.

Il faut être d’autant plus vigilant aux problèmes de performance que le mobile est devenu la manière préférée pour consommer le web. Pour autant, le temps de chargement d'une page sur mobile est en moyenne de 15,3s.

Lighthouse est un outil conçu par Google et sorti en Avril 2018.

Attention, ça n'est pas une source de vérité. On ne sait pas vraiment comment le score est calculé. Il permet de mesurer la qualité du site web, mais ça n'est pas une finalité suffisante.

Pour savoir si Google Lighthouse est un bon outil, il faut prendre en compte deux aspects :

• les données
• le contexte

Comment fonctionne Lighthouse ?

• Pour les données, il y a ce calculateur qui permet de voir quel poids Google attribue à 5 critères.

Attention, ce score de performance change entre chaque version !

• Pour le contexte, il faut savoir que le résultat dépend énormément de quand et où vous lancez l'audit : connexion internet, CPU, extensions chrome, etc.

Il est donc important d'utiliser la navigation privée pour lancer un test !

De manière générale, pour qu’un test soit fiable, il doit être reproductible dans les mêmes conditions !

Une alternative plus fiable serait Page Speed Insights.

Il faut rester prudent avec le score fourni Lighthouse, car il est très simple de la contourner :

• 
• Un article avec un super score LightHouse mais terrible en accessibilité
• Un tricheur

La performance n’est pas non plus le Graal, car elle vient aussi avec des compromis et, parfois, ils ne sont pas acceptables (par exemple retirer une fonctionnalité).

Comment utiliser Lighthouse donc ?

On peut l’utiliser pour voir à quel point une nouvelle version de notre app va affecter la performance ou pour se comparer à la concurrence. En effet, il est difficile de comparer deux domaines. Par exemple, pour un blog on s'attend à avoir un score élevé proche de 100%, mais pour un e-commerce, un score de 60% serait certainement un score acceptable ! Enfin, Lighthouse ne sert pas à mesurer l'expérience des utilisateurs sur notre app !

Pour résumer :

1. Un bon score Google Lighthouse ne veut pas dire que l'expérience des utilisateurs est bonne.
2. Utiliser Lighthouse pour avoir une idée générale de la performance de son site web entre chaque version. Un score vert c’est bien, mais ça ne signifie pas que le site est rapide.
3. Tout ce que Lighthouse identifie comme un problème n'en est pas forcément un et les résultats vont dépendre d'où et quand vous lancez le test. Essayez de faire vos tests en isolant au maximum votre environnement des influences extérieures.
4. Le score de Lighthouse n'a pas grand-chose à voir avec la performance chez vos utilisateurs. Utilisez plutôt le Chrome User Experience Report pour connaître l'expérience de vos utilisateurs.

Optimiser les performances de Vue.js sur une grosse application - Aurélie Violette (Replay)

Chez Weweb, entreprise française spécialisée dans une solution NoCode, on utilise Vue.js. La codebase est très importante et l'équipe chargée du projet doit faire face à des problématiques de performance intéressantes.

On y découvre des outils et astuces pour améliorer les performances :

• Tout d'abord, il est possible de configurer son application Vue.js pour mieux évaluer où les problèmes de performance se situent : app.config.performance. = true
• Utiliser l'onglet "Performance" de son DevTools.
• Utiliser le DevTools de Vue.js qui fournit aussi des indicateurs de performance.
• Les méthodes du cycle de vie : renderTracked, renderTriggered + onTrack et onTrigger.

Dans la démonstration, on découvre les problèmes qu'on peut rencontrer en Vue.js et comment on peut y remédier.

Attention, ça n’est pas parce qu'on travaille sur une application sous Vue.js que c'est forcément la faute de Vue.js si on a un problème de performance.

“On peut faire faire des choses idiotes à un framework intelligent.”

Dans un exemple de la démonstration, on a une boucle for avec une computed pour déterminer si un élément est affiché ou non. Alors quand la computed change, par défaut, tous les éléments de la boucle sont rendus à nouveau, ce qui n’est pas optimal.

Pour optimiser ça, on a donc plusieurs solutions :

• child components
• v-memo :

• "lazy" ref :

Merci d’avoir lu ce résumé de la première partie du premier jour de la Vue.js Amsterdam 2023.

Vous trouverez la suite juste ici : Partie 2.