Lightning CSS sur Vite v4.4.0 ⚡ - Actus JS de la semaine (10 juillet 2023) - Vidéo Dailymotion

DevTheory

Découvrir le Plan d'Action de Maintenabilité : https://go.devtheory.fr/maintainable-codebase?utm_source=youtube&utm_campaign=actus_100723  Article: "CommonJS is hurting JavaScript" par Deno : https://deno.com/blog/commonjs-is-hurting-javascript Article: "CommonJS is not going away" par Bun : https://bun.sh/blog/commonjs-is-not-going-away Actu: Vite v4.4.0 - Ajout de Lightning CSS : https://github.com/vitejs/vite/blob/main/packages/vite/CHANGELOG.md#440-2023-07-06 Lib: Radash - Functional utility library : https://radash-docs.vercel.app/docs/getting-started Service: Plan d'action de maintenabilité : https://go.devtheory.fr/maintainable-codebase?utm_source=youtube&utm_campaign=actus_100723  -------------------------------------------------------------------- DevTheory   Formations : https://devtheory.fr/?utm_source=youtube&utm_medium=yt_description Discord : https://go.devtheory.fr/discord Twitter: https://go.devtheory.fr/twitter LinkedIn : https://go.devtheory.fr/linkedin  -------------------------------------------------------------------- Informations  00:00 - Introduction 00:31 - Actu: Le débat CJS vs ESM de retour 07:12 - Actu: Vite v4.4.0 - Ajout de Lightning CSS 09:27 - Lib: Radash - Functional utility library 11:03 - Service: Plan d'action de maintenabilité 14:09 - Conclusion  Contact partenariat : https://go.devtheory.fr/partenariat

Transcript

00:00 Le débat entre CommonJS et ECMAScript modules de retour,

00:04 ainsi que la version 4.0.0 de Vite,

00:07 bienvenue dans les actualités de la semaine du lundi 7 juillet 2023.

00:11 Et nous parlerons également en fin de vidéo d'un nouveau service

00:14 que je lance dédié aux entreprises pour réduire leur dette technique

00:18 sur les codebase Vue.js et Nuxt.

00:21 C'est parti !

00:22 Bonjour à tous, c'est Brian de Dev Theory,

00:28 la chaîne pour devenir et rester un bon développeur JavaScript.

00:31 Cette semaine, on va parler d'un nouveau débat

00:34 qui a eu lieu dans l'écosystème de JavaScript

00:36 et qui reprend le débat qu'il y avait eu concernant CommonJS

00:41 et ECMAScript modules.

00:42 Ici, on va parler notamment de deux technologies,

00:45 Deno et Bun.

00:46 Deno et Bun sont des alternatives à Node.js,

00:49 ce sont également des technologies qui vont exécuter du JavaScript

00:53 dans un environnement JavaScript.

00:56 Ici, pour remettre les choses dans leur contexte,

00:59 qu'est-ce que CommonJS et ECMAScript modules ?

01:01 CommonJS, c'est la manière d'importer des modules

01:05 à travers le mot-clé "require" et "module.export".

01:08 C'est le premier système de modules qui a existé

01:12 et qui a notamment été très démocratisé par Node.js.

01:16 Tous les scripts Node.js d'il y a quelques années,

01:19 mais encore beaucoup aujourd'hui,

01:20 c'est avec du require que l'on importe des fichiers ou des librairies externes.

01:25 Alors que ECMAScript modules, donc ESM,

01:28 c'est la nouvelle manière de faire qui a été introduite à partir de ES6.

01:32 C'est la manière de gérer les modules de base pour JavaScript,

01:38 puisque c'est ECMAScript qui définit ça et comment JavaScript fonctionne.

01:41 C'est un système de modules officiel de JavaScript

01:44 qui est vraiment inclus dans le langage

01:46 et qui se détermine par les mots-clés "import from",

01:50 que vous connaissez sûrement, ainsi que "export".

01:52 Tous ces mots-clés-là, c'est à travers le système ESM,

01:55 alors que require et module.export, c'est du CommonJS.

01:58 Voilà pour le contexte.

01:59 Et donc, qu'est-ce qui se passe cette semaine ?

02:01 Il se passe que le 30 juin, il y a une semaine et demie,

02:06 Deno a créé un article qui s'appelle

02:09 "CommonJS fait mal au JavaScript",

02:13 donc fait mal à l'écosystème de JavaScript.

02:16 Alors, qu'est-ce qu'ils disent dans cet article-là ?

02:17 Ce qu'ils disent déjà, c'est qu'ils commencent à donner un petit historique,

02:21 comme je vous ai fait par rapport à CommonJS,

02:23 que ça est arrivé en 2009,

02:24 parce que le JavaScript commençait à aller côté serveur.

02:27 D'ailleurs, au départ, ça s'appelait "server.js", ce système-là.

02:30 Et donc, ensuite, ça a été démocratisé par Node.js, etc.

02:33 Ensuite est venu donc "xmascript.module.esm",

02:38 donc à partir de "xmascript.sys" de JavaScript.

02:40 Et donc, Node.js a décidé d'adopter les deux,

02:43 d'adopter à la fois CGS et ESM, afin d'être à la fois moderne,

02:47 mais également de garder le gros système de modules,

02:49 tous les modules qu'il y avait sur NPM déjà existants.

02:52 Et donc, le souci avec ça, c'est que maintenant,

02:55 si on veut faire un paquet, donc un module NPM,

02:57 un paquet NPM qui est compatible à la fois sur les ESM et sur CGS,

03:02 eh bien, en fait, on a des scripts d'exportation qui sont,

03:06 en fait, voilà, qui sont, voyez, huit lignes.

03:07 On a huit lignes pour, en fait, uniquement,

03:10 et avec quasiment quatre fichiers de configuration différents de vite,

03:13 pour avoir un paquet qui est à la fois supporté par le système ESM et CGS.

03:18 Donc, en fait, pour que notre paquet soit disponible pour tous les développeurs,

03:22 quels que soient leurs code base, qu'elle soit sur ESM ou sur CommonJS.

03:26 Donc, ça, c'est dit qu'effectivement, c'est un problème

03:28 parce que le fait de supporter ces deux-là,

03:29 ça crée vraiment beaucoup de code en plus qui ne sert pas forcément à grand-chose.

03:33 Et donc, ils disent qu'il faudrait un moment,

03:36 eh bien, voir dans le futur, d'arrêter en fait CommonJS,

03:39 de mettre une date de fin, de mettre un end of life à Node.js,

03:43 afin qu'il y ait seulement, enfin à CommonJS,

03:47 afin qu'il y ait seulement donc ESM qui reste,

03:49 parce que c'est la manière moderne et c'est la manière la plus...

03:52 également la plus préférée de développer avec pour les développeurs.

03:57 Donc, ça, c'est ce que disent Deno.

03:59 Ensuite, Bunn.

04:01 Bunn, c'est également un environnement de développement pour JavaScript.

04:05 Et qu'est-ce qu'ils disent ?

04:05 Eh bien, ils disent en fait que CommonJS ne va nulle part,

04:09 en fait, dans le sens où il va totalement rester.

04:11 Il va rester dans l'environnement JavaScript,

04:14 il n'est pas prêt de s'en aller.

04:16 Alors, pourquoi ils disent ça ?

04:17 Il s'appuie notamment sur quelques données,

04:18 notamment ces données-là.

04:19 Ici, on voit donc, c'est la répartition du système de modules

04:23 sur tous les paquets NPM.

04:24 Donc, par exemple, on peut voir que 73% des paquets NPM,

04:28 donc de tous les paquets NPM, sont écrits en CommonJS,

04:31 tandis que seulement 9% sont écrits en ESM

04:34 et un peu moins de 4% supportent les deux.

04:37 En plus, on a des faux ESM qui sont en fait des ESM qui ne sont pas...

04:40 qui ne sont pas compatibles ou qui ne sont pas vraiment dans les normes exactes,

04:44 notamment par rapport à Webpack, etc.

04:46 Donc, en fait, vous voyez que 9%, 73%,

04:48 il y a encore une dominance très large de CommonJS.

04:51 Donc, ils disent que c'est un peu un non-sens

04:53 de commencer à dire qu'il va falloir enlever CommonJS, etc.

04:57 parce que c'est encore très, très majoritaire.

04:59 On est sur les trois quarts, ici, on est plus sur les trois quarts.

05:01 Donc, c'est vraiment extrêmement majoritaire,

05:03 même si on voit que petit à petit, ça descend.

05:04 On voit que ça descend.

05:05 En 2021, on était à 77%.

05:07 En 2022, on est à 73%.

05:09 Donc, ça descend, mais c'est quand même très lent, en fait.

05:12 Donc, il faut continuer à supporter CommonJS,

05:14 et c'est ce qu'ils disent.

05:15 Et ils donnent également un autre argument.

05:17 L'autre argument, c'est l'argument de la vitesse.

05:20 Effectivement, CommonJS,

05:23 les modules sous CommonJS, ce système de modules-là,

05:25 est plus rapide quand on est sur des applications très larges.

05:29 Alors, on a un exemple assez simple,

05:31 c'est l'importation de BabelCore.

05:33 BabelCore, c'est effectivement un paquet

05:34 qui a énormément de sous, de fichiers, etc.

05:37 Donc, c'est vraiment beaucoup de choses à importer.

05:38 Donc, si on fait un simple require de BabelCore

05:41 ou un simple import de BabelCore,

05:43 donc on est bien sûr du CommonJS et ici sur de l'ESM,

05:47 eh bien, en fait, on a une différence de 85 millisecondes

05:50 en faveur de CommonJS au niveau de l'exécution.

05:53 Et donc, là, c'est sur BUN,

05:56 mais sur Node.js, on a également 60 millisecondes.

05:58 Donc, on pourrait dire que c'est quand même important.

06:00 Effectivement, sur du call start en serverless,

06:03 eh bien, 85 millisecondes et 60 millisecondes,

06:05 c'est quand même une durée très importante, non négligeable.

06:09 Mais là, c'est bien sûr pour l'importation totale de BabelCore,

06:12 ce qui arrive assez rarement.

06:13 Mais pour des applications qui ont beaucoup de choses,

06:15 eh bien, CGS est plus rapide.

06:17 Et pourquoi c'est plus rapide ?

06:19 Eh bien, simplement parce qu'en fait,

06:20 l'ESM se base sur de l'asynchrone.

06:23 Ça veut dire qu'à l'instant où on a un import ou quoi,

06:25 eh bien, en fait, ça va asynchroniquement,

06:27 je ne suis pas sûr de ce mot-là,

06:28 eh bien, va venir récupérer tous les paquets

06:32 ou tous les sous-fichiers, etc.

06:33 Alors que require, eh bien, c'est synchrone.

06:35 En fait, le fait qu'il y ait de l'asynchrone,

06:37 ça va entraîner certains micro-ticks et overhead,

06:40 donc certains systèmes de queues

06:42 qui vont être mis en place au sein du moteur JavaScript.

06:45 Alors que le fait que ce soit synchrone,

06:46 eh bien, ça n'entraîne absolument pas ça.

06:48 Donc, on va avoir tout ça en moins.

06:49 Et ça se ressent sur de larges applications

06:52 comme le fait d'importer tout Babel.

06:53 Ça, c'est également un exemple en plus qui montre

06:55 que require peut être plus efficace de temps en temps.

06:58 Ce qu'ils disent, c'est qu'il faut en se marier.

07:01 Pour résumer, ils disent qu'il ne faut absolument pas

07:04 mettre CommonJS de côté

07:05 et qu'il faut accepter le fait qu'il y ait les deux,

07:07 qu'il y ait ESM et CommonJS

07:09 et que ça va rester comme ça pour un très bon moment.

07:11 Autre chose cette semaine, c'est la sortie de Vite version 4.4.

07:15 Alors, Vite version 4.4, qu'est-ce que ça apporte ?

07:18 Ça apporte surtout une chose importante,

07:20 c'est le support de Lightning CSS.

07:22 Alors, qu'est-ce que c'est que ça que Lightning CSS ?

07:24 Eh bien, en fait, c'est un parseur, un transformeur,

07:27 un boodleur et un minifieur de CSS.

07:30 Qu'est-ce que ça veut dire ?

07:31 Ça veut dire tout simplement que si on essaye de minifier

07:33 le code de Bootstrap,

07:34 donc le code que les développeurs de Bootstrap

07:36 écrivent pour de vrai, qu'on essaye de minifier,

07:38 donc c'est à peu près 10 000 lignes,

07:40 eh bien, CSS nano, qui est utilisé notamment par Webpack, je crois,

07:44 eh bien, c'est 500 millisecondes.

07:45 ESBuild, qui est la version actuelle,

07:48 qui est utilisée, enfin avant,

07:49 enfin qui est utilisée actuellement sur Vite,

07:51 eh bien, c'est 17 millisecondes.

07:53 Donc, vous voyez que c'est déjà extrêmement peu

07:55 pour 10 000 lignes de code.

07:56 Minifier 10 000 lignes de code en 17 millisecondes,

07:58 c'est vraiment impressionnant.

07:59 Alors que Lightning CSS, eh bien, fait du 4,16 millisecondes.

08:03 Donc, on est vraiment encore sur une différence très importante

08:06 entre ces deux-là.

08:07 Et de plus, l'output size, donc le fichier final,

08:10 en fait, encore une fois, par rapport à cette modification de Bootstrap 4,

08:13 eh bien, sur Lightning CSS, on arrive à 140 kilobytes,

08:17 alors que sur ESBuild, on est à 156.

08:19 Donc, vous voyez qu'il y a même un avantage également

08:21 sur le fichier final, en plus de la vitesse

08:24 dont a été créé ce fichier-là.

08:26 Donc, Lightning CSS, c'est une superbe chose pour Vite.

08:31 Et donc, actuellement, il est supporté,

08:34 mais il n'est pas mis par défaut.

08:36 Ça veut dire que pour le mettre par défaut,

08:38 il faut faire CSS.Transformer Lightning CSS

08:40 au sein de votre fichier de configuration Vite.

08:45 Mais ça, c'est pour le transformer,

08:46 c'est-à-dire que c'est pour le mode de développement.

08:49 Quand vous allez développer, quand vous allez écrire votre CSS,

08:51 eh bien, ça ne va plus être PostCSS qui sera pris en compte

08:54 pour créer le CSS qui va être exécuté au niveau du navigateur,

08:57 mais ça va être Lightning CSS.

08:59 Et si vous voulez l'utiliser en tant que minifieur,

09:02 donc, ça veut dire que là, au niveau du bundle final,

09:04 eh bien, vous devez faire build.cssminify et là, mettre Lightning CSS.

09:08 Et je crois qu'ici, c'était ESBuild et non PostCSS,

09:11 mais je ne suis pas sûr.

09:13 Voilà, en tout cas, pour cette version 4.4.

09:14 Donc, je vous conseille de tester Lightning CSS,

09:16 qui peut être une bonne chose pour éventuellement réduire votre durée de build,

09:20 mais également même réduire votre durée de rebuild,

09:24 de hot module reloading lorsque vous développez.

09:26 Maintenant, au niveau de la librairie de la semaine, c'est Radash.

09:30 Alors, Radash, c'est une nouvelle librairie.

09:32 Enfin, elle n'est pas nouvelle, c'est la version 10,

09:34 mais moi, je l'ai découverte assez récemment.

09:36 Et donc, qu'est-ce que c'est que cette librairie-là ?

09:38 Eh bien, c'est un peu un loadash,

09:40 mais un loadash qui se veut moderne et typé de base.

09:42 Donc, par exemple, en fait, il va donner certaines fonctions

09:45 qui sont assez intéressantes, comme try.

09:47 Try, c'est une fonction qui est assez intéressante,

09:49 puisqu'elle permet d'éviter d'avoir un try-catch

09:51 et d'englober une certaine méthode dans un try-catch,

09:55 ensuite d'envoyer des paramètres pour cette méthode-là,

09:57 et ensuite, ça va renvoyer un array de deux éléments,

10:00 l'erreur et la réponse, en fait.

10:02 Donc, si jamais il y a une erreur,

10:04 alors on peut show une nouvelle erreur en disant plus de détails, etc.

10:08 Donc, je trouve que c'est une bonne méthode, une bonne manière,

10:11 parce que le try-catch, c'est vrai que ça fait un peu d'intentation, etc.

10:14 et que ça fait beaucoup de boilerplate pour pas forcément grand-chose,

10:17 alors qu'ici, le try est assez efficace.

10:19 Et ensuite, il y a plein d'autres méthodes par rapport aux arrays.

10:22 Il y a plein d'autres méthodes, voilà, du flat, du min, du max.

10:26 Ce que j'aime bien, c'est que c'est très typé.

10:28 Donc, en fait, de base, ça fonctionne avec TypeScript.

10:30 Par exemple, pour du max, ici, on met le ray,

10:32 ensuite, on met la méthode pour récupérer la valeur qui doit être min ou max,

10:37 et derrière, ça va nous récupérer ici le max de weight,

10:41 donc c'est-à-dire 105 par rapport à ces trois-là.

10:43 C'était effectivement celui-là qui était en max.

10:44 Bref, il y a plein de petites méthodes, etc.

10:47 Et comme je vous disais, il se veut un peu le concurrent de l'audache, mais moderne.

10:51 Il dit qu'il ne va pas provide, il ne va pas donner des méthodes,

10:54 comme par exemple map ou filters,

10:55 parce qu'elles sont maintenant disponibles de base en JavaScript,

10:58 donc ça n'a pas de sens de les avoir dans une librairie.

11:01 Il dit que l'audache, ça n'a pas de sens d'avoir ça.

11:03 Et enfin, je vous présente un nouveau service que je mets en place avec Dev Theory,

11:07 qui se trouve être le plan d'action de maintenabilité,

11:10 qui vous permet de réduire la dette technique de votre codebase Vue.js ou Nuxt,

11:15 et ce, à travers un plan d'action que je rédige pour vous après mon analyse,

11:19 et qui est très clair et réalisable.

11:21 Alors ici, je vous donne certains avantages de la maintenabilité,

11:23 mais si vous êtes un libdev ou un CTO,

11:25 bien sûr, vous savez déjà tous les avantages

11:27 que donne une meilleure maintenabilité.

11:29 Donc ça se passe en trois étapes.

11:30 On prend contact juste pour savoir si votre codebase est cohérente

11:33 par rapport aux compétences que j'ai pour l'analyse.

11:36 Ensuite, j'accède à votre codebase après la signature d'un NDA,

11:40 bien sûr, parce que votre code est très important,

11:43 c'est important d'avoir une sécurité là-dessus.

11:44 Ensuite, sous deux semaines après, vous voyez, jour 8 à jour 14,

11:48 je vous livre le plan d'action détaillé.

11:51 Et donc voilà, là, je détaille un peu la méthode d'analyse,

11:53 et on peut même voir l'exemple du plan d'action.

11:55 Voilà ici un exemple de plan d'action.

11:57 Là, on a l'introduction.

11:58 Ensuite, on a les problèmes identifiés.

12:00 Alors, ce plan d'action a été fait sur un projet open source

12:02 qui est sur Vue.js.

12:03 Donc voilà, je voulais faire un petit peu un petit exemple,

12:05 donc j'ai pris un projet open source

12:07 et j'ai essayé de faire cette analyse-là,

12:08 donc ce plan d'action de maintenabilité.

12:10 Donc si on descend un petit peu pour voir un peu à quoi ça ressemble,

12:12 concrètement, vous voyez, là,

12:13 j'ai identifié tout d'abord des problèmes liés aux technologies.

12:16 Ici, il y avait l'utilisation de la version 2.

12:18 J'explique pourquoi c'est un problème d'utiliser la version 2 de Vue.js.

12:22 J'estime le temps également de changement,

12:25 le niveau d'importance sur 3.

12:27 Ici, vous voyez, c'est un N3, donc c'est un niveau 3.

12:29 C'est très important de changer ça.

12:30 Ça va avoir un gros impact sur la maintenabilité.

12:33 Et ensuite, je propose ma résolution,

12:35 simplement de mettre à jour Vue.js 3,

12:37 ainsi que tous les paquets,

12:38 ici, leur équivalence vers Vue.js 3 parce qu'ils étaient sur Vue.js 2.

12:41 Et on va avoir ça pour pas mal de sous-catégories

12:44 liées aux paquets NPM également,

12:46 liées à la configuration de S-Lint.

12:48 Il y avait 67 d'occurrence pour disable une roule no-endef.

12:52 Donc, j'explique comment en fait avoir une meilleure configuration

12:55 pour ne pas avoir ces 67 occurrences-là,

12:57 qui est vraiment pas ouf.

12:58 Quelques exemples de code également parfois.

13:00 Des problèmes liés à Vue.js Direct,

13:02 des problèmes liés à JavaScript Directement

13:04 ou aux commentaires un peu plus bas.

13:05 Et ensuite, une fois que tout ça, c'est fait,

13:07 je vous explique une feuille de route que je recommande.

13:10 Une feuille de route précise

13:12 sur d'abord faire la migration de Vue.cli vers Vite,

13:15 ensuite de Vue.js vers sa version 3,

13:17 puis la documentation du code,

13:18 puis la renflatterisation vers la Composition API,

13:20 puis le typage du code.

13:21 Vous voyez que là, c'est une roadmap

13:23 qui a été fait spécialement pour cette codebase-là.

13:26 Et elle a du sens, cette roadmap,

13:27 dans le sens où chaque étape va vous aider à faire celle d'après.

13:30 Par exemple, la documentation du code,

13:31 c'est quelque chose qui va évidemment vous aider pour le typage.

13:34 Parce que si vous commencez à faire le typage

13:35 sans avoir documenté votre code d'abord

13:37 et que vous avez un problème de documentation,

13:39 eh bien le typage, il va être beaucoup plus long que nécessaire.

13:41 Donc voilà, j'essaie vraiment de faire quelque chose de très complet.

13:43 Et tout ça, c'est présent dans le plan d'action de maintenabilité.

13:47 Après la réception de ce plan,

13:48 je vous propose également certains services inclus de base,

13:51 notamment le fait d'avoir un appel,

13:53 un appel personnalisé avec vos développeurs

13:56 pour expliquer un peu le plan d'action.

13:58 Ensuite, une assistance par email pendant un mois.

14:00 Et également, j'offre à cinq de vos développeurs

14:02 notre cours sur le Clean Code appliqué au JavaScript.

14:06 C'est un cours d'une heure trente,

14:07 donc ça peut être intéressant d'avoir également tout ça.

14:09 Voilà concernant le plan d'action de maintenabilité.

14:12 Je vous mets ce petit lien-là juste en dessous, en description,

14:14 ainsi que le lien de toutes les autres ressources dont on a parlé.

14:18 Aujourd'hui, je vous souhaite une très, très bonne semaine.

14:21 On se retrouve bien sûr dès lundi prochain.

14:23 N'hésitez pas à vous abonner à cette chaîne.

14:25 À très vite et bon codage !

14:27 (Musique)

14:30 (Musique)

14:33 (Musique)

14:36 (Musique)

14:39 ♪ ♪ ♪

Lightning CSS sur Vite v4.4.0 ⚡ - Actus JS de la semaine (10 juillet 2023)

Category

Transcription

Recommandations