# LTE - Javascript :::info Texte d'introduction [à rédiger] ::: ## Bonnes pratiques ### Importer que les modules que l'on utilise De nombreuses librairies javascript permettent de résoudre une multitudes d'actions complexes (MomentJs, Lodash, D3). Cependant, ces librairies sont assez lourdes pour justement traiter ces différents problèmes. Lorsque vous n'utilisez pas la globalité des méthodes proposées par ces librairies, il peut être intéressant de se renseigner si ces librairies proposer un découpage de leur fonction en module qui peuvent être importés séparemment ou s'il existe des alternatives que ne font que le point précis que l'on cherche à résoudre. Exemple : [Lodash pèse 70kB minifié](https://bundlephobia.com/result?p=lodash@4.17.20). [Lodash.isEqual pèse 10kB minifié](https://bundlephobia.com/result?p=lodash.isequal@4.5.0) ### Choix d'un framework Il est souvent utile d'utiliser un framework pour développer de manière structurée, modulable, et réutilisable son code en Javascript. De nombreux frameworks existent : [React](https://reactjs.org/), [Vue.js](https://vuejs.org/), [Angular](https://angular.io/), [Svelte](https://svelte.dev/). Ces frameworks simplifient le développement de certains fonctionnalités pour les développeurs. Le choix d'un framework n'est jamais évident, et il doit se baser sur beaucoup de critères. Certains frameworks mettent en avant leur performance (Svelte, Vue.js), d'autres leur versatilité (React) ou encore leurs outils (Angular). Il convient donc d'étudier les différents frameworks en fonction du projet : la familiarité de l'équipe de développement avec le framework, sa maturité, sa capacité à répondre aux problématiques soulevés par le projet, ainsi que le nombre de personnes utilisant ce framework également. :::warning A améliorer Utiliser un framework ou non : - seul ou en équipe - cadre les usages ::: ### Polyfill et Transpiler Le web étant en constante évolution, les utilisateurs de votre projet peuvent utiliser des anciennes versions de navigateur, ou alors des navigateurs ne supportant pas la globalité des dernières fonctionnalités du langage. JavaScript évolue via le [TC39](https://tc39.es/) et les propositions. Certains navigateurs (et runtime) peuvent donc être en avance sur les autres, et d'autres peuvent choisir de n'implémenter que les propositions à l'état 4. :::warning Il peut être intéressant de se renseigner sur l'état d'une proposition avant son utilisation. Par exemple, les [décorateurs](https://github.com/tc39/proposal-decorators) sont encore à l'état 2, et il faut donc utiliser [un transformateur](https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy) en fonction ::: Afin de faciliter l'utilisation de nouvelles fonctionnalités, tout en maintenant le compatibilité avec les anciennes versions de navigateurs, il peut être intéressant de faire usage de polyfill ou de transpilers (dans le cas d'usage d'outil comme [Babel](https://babeljs.io/), [Webpack](https://github.com/webpack/webpack), etc...). Des outils comme ce [tableau comparatif](https://kangax.github.io/compat-table/es2016plus/), [MDN](https://developer.mozilla.org/en-US/) ou [Can I use](https://caniuse.com) permettent de connaître la compabilité d'un méthode. Dans certains cas, pour des fonctions très bien supportées mais pas disponiblse pour un navigateur en particulier, plutôt que d'allourdir le javascript pour tous les utilisateurs, il peut être intéressant de charger le polyfill que pour ce navigateur, ou dans le cas d'un code _bundlé_, de créer un _build_ spécifique pour cette compatibilité. https://philipwalton.com/articles/loading-polyfills-only-when-needed/ https://3perf.com/blog/polyfills/ ## Les cas pour bien comprendre en contexte ### Cas n°1 : Lodash https://www.blazemeter.com/blog/the-correct-way-to-import-lodash-libraries-a-benchmark Lodash est une librairie Javascript de fonction outils permettant de réaliser de façon très simple de nombreuses méthodes : manipulation de tableaux, d'objets, de chaines de caractères, clone, filtre, etc... Par défaut, l'import de lodash dans un projet de cette façon : ```javascript import _ from "lodash"; ``` Va présenter le défaut de charger l'ensemble de la librairie, alors que potentiellement, que certaines méthodes sont utilisés. Il est donc recommandé de charger uniquement les méthodes de lodash de manière individuelle : ```javascript import map from "lodash/map"; import tail from "lodash/tail"; ``` Il peut aussi être utile, pour simplifier ce genre d'import, d'utiliser le [plugin babel](https://github.com/lodash/babel-plugin-lodash) permettant de ne charger que les modules utiles. Une autre possibilité, mise en avant depuis quelques temps dans la documentation, est de ne mettre en [dépendances que les modules](https://www.npmjs.com/search?q=keywords:lodash-modularized) que l'on utilise, ce qui permet d'éviter de charger l'entierreté de la libraire lodash : ``` npm i --save lodash.merge ``` ### Cas n°2 : MomentJs https://momentjs.com/docs/#/-project-status/ https://github.com/you-dont-need/You-Dont-Need-Momentjs/blob/master/README.md MomentJs est une des librairies de gestion des dates les plus utilisé en Javascript. Elle a l'avantage de proposer des fonctions pratiques à utiliser et manipuler des dates de façons très simples. Depuis quelques années cependant, avec les nouvelles versions d'ECMAScript, la manipulation de date s'est grandement améliorée. Depuis Septembre 2020, MomentJS pousse les nouveaux projets à ne pas l'utiliser mais à privilégier les méthodes natives ou alors des librairies plus légères (date-fns, Day.js, etc...). Autre point négatif de MomentJs est sa gestion des locales. Par défaut, la librairie vient avec l'ensemble des locales supportés, ce qui allourdit grandement le code servi à l'utilisateur pour souvent aucun usage de sa part. Il est possible de configurer les bundlers (type webpack) pour ignorer une partie des locales non utilisés mais par défaut, MomentJs pèse 329kB, là où les autres librairies pèsent entre 5 et 80kB. Il est donc recommandé de se passer de MomentJs dans la mesure du possible. ### Cas n°3 : JavaScript DOM ManipulationPerformance http://www.diva-portal.org/smash/get/diva2:1436661/FULLTEXT01.pdf La manipulation du DOM est une opération couteuse, que ce soit en Vanilla JavaScript (sans framework) ou à l'aide d'un framework. Morgan Persson a étudié les différents frameworks (React, VueJS et Angular) pour les comparer à des solutions en vanilla JS afin de déterminer l'impact de ces frameworks et leurs performances sur des éléments du DOM. Il en ressort que, logiquement, le vanilla JS est plus rapide et léger, mais aussi que les performances sur la manipulation du DOM n'est pas le critère déterminant au choix d'un framework. ## Ressources complémentaires - [The Cost of Javascript Frameworks](https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/) - [JavaScript Frameworks, Performance Comparison 2020](https://javascript.plainenglish.io/javascript-frameworks-performance-comparison-2020-cd881ac21fce)