JavaScript, l'un des piliers sur lesquels repose l'ingénierie des contenus Web, a atteint le Club du quart de siècle. Il existe depuis longtemps et, peu importe comment vous le considérez, son importance est indéniable.
Je vais m'atteler ici à la tâche ambitieuse de analyse de l'écosystème JavaScript, en commençant par décrire l'histoire de ce langage de programmation et, plus tard, en abordant les différentes technologies frontales et dorsales qui y sont présentes. Mais d'abord, répondons La question où tout a commencé.
JavaScript est un langage de programmation créé par Brendan Eich en 1995. C'était l'époque de guerre des navigateurs entre les navigateurs : Internet Explorer et Netscape Navigator se battaient pour proposer de nouvelles fonctionnalités et il n'y avait pas de temps à perdre.
M. Brendan Eich, un technologue américain, travaillait pour Netscape et a dû créer un langage de programmation qui permettrait développeurs frontaux pour intégrer de petits programmes dans des pages Web, afin de les rendre plus interactives et dynamiques. Le produit final devait être flexible, facile à apprendre, avoir un attrait populaire et être facile à mettre en œuvre.
M. Eich n'avait que 10 jours ouvrables pour produire la première implémentation, ce que nous avons confirmé auprès de l'homme lui-même, mais, contre toute attente, il a réussi à la livrer.
Voici quelques langages de programmation existants qui ont influencé le résultat :
Le langage a été développé sous le nom Moka et, plus tard, publié avec Netscape sous son nom de facto actuel : JavaScript.
Une question inévitable qui se pose souvent à cause de la racine de son nom, à laquelle la réponse est assez courte : Tout, à l'exception de certains éléments de syntaxe tels que les crochets, les points, les points-virgules, qui expriment constructions analogues dans les deux langues. Le nom choisi était une initiative marketing de Netscape, afin de mettre en valeur sa nouvelle création en s'appuyant sur le battage médiatique de l'époque : Java.
JavaScript étant un succès, Microsoft l'a rétroconçu afin de concurrencer Netscape, en publiant sa propre version sous le nom de JScript.
Dès le début, il y avait plusieurs incompatibilités entre les différentes implémentations du langage et, afin de réduire l'impact de ce problème, Netscape a soumis JavaScript pour standardisation par le Ecma International organisation de normalisation en 1997.
La version standardisée qui en a résulté a été nommée Script ECMA et a progressivement atteint l'acceptation universelle en tant que spécification linguistique. Malgré cela, le nom JavaScript est resté utilisé comme nom de facto du langage.
Afin d'ajouter de nouvelles fonctionnalités au langage et de le rendre compatible avec les travaux d'autres organismes de normalisation, la norme a changé de temps à autre.
Les livrables de chaque version sont connus sous le nom de « ECMAScript » et je vais énumérer ici une brève description de certains des changements les plus pertinents pour chacune d'entre elles.
La première version de la norme linguistique.
Cette version a été produite en 1998 alors que la langue était également normalisé par ISO/IEC. Il a mis à jour la norme Ecma afin qu'elle corresponde au document produit par l'ISO/IEC.
En 1999, plusieurs nouvelles fonctionnalités ont été ajoutées à la langue. Les plus remarquables étaient les suivants :
• Littéraux d'expressions régulières;
• Nouvelles déclarations de contrôle;
• Gestion des exceptions.
Ce projet de version a été abandonné en 2008 en raison de désaccords concernant ses fonctionnalités. Il a été décidé que le résultat était trop radical pour être introduit et il a été convenu de créer une version intermédiaire avant que des développements aussi radicaux n'aient lieu.
La version compatible avec la plupart des navigateurs début 2016 a été créée en 2009. Ses caractéristiques les plus remarquables étaient les suivantes :
• Fonctions d'itération d'ordre supérieur (cartographier, réduire, filtrer, ForEach) ;
• Support JSON;
• Getters et setters;
• Meilleures propriétés de réflexion et d'objet;
Tout comme ECMAScript 2, cette spécification a été produite pour aligner la norme ECMA sur le document produit par l'ISO/IEC pour ECMAScript 5.
Cette version a ajouté plusieurs changements importants en 2015, à savoir :
• Promesses.
• Modules;
• Cours;
• Déclarations de variables à portée de blocs (gauche) ;
• Fonctions de la flèche;
• Modèle littéral;
• Opérateur de propagation;
• Mission déstructurante;
• Valeurs par défaut des paramètres;
• Paramètres de repos;
• Symboles;
• Fonctions du générateur.
Cette version uniquement fabriqué modifications mineures <Array.includes>au langage, par exemple en ajoutant un opérateur d'exponentiation et en spécifiant la méthode.
Le support du navigateur pour cette version est incomplet, bien qu'il existe un transpileur qui convertit le code ES6 en versions ES plus anciennes.
Ajoute principalement la prise en charge des fonctions asynchrones.
Cette version élargit la boîte à outils des expressions régulières et introduit le reste et propager opérateurs pour les littéraux d'objets. C'est enfin présente <Promise.finally>comme un moyen astucieux de rationaliser les comportements qui devraient toujours se produire indépendamment du résultat de la promesse.
La dixième interaction apportées <Array.flat>et <Array.flatMap>méthodes, tout en assouplissant la liaison d'erreur catch block qui a attiré une attention accrue grâce à l'introduction par ES2017 de asynchrone et attendre.
Bien que le projet de cette version soit loin d'atteindre son onzième heure, on peut déjà compter sur Opérateur de coalescence nul et Opérateur de chaînage en option cela améliorera sans aucun doute la lisibilité du code.
<Promise.all>Promises étendra également son API avec AllSettled, une alternative à cela se résout toujours par une description du résultat de chaque promesse où qu'ils soient résolus ou rejetés.
Alors que JavaScript a commencé son parcours en répondant à la nécessité de rendre les pages Web plus interactives et dynamiques, il a parcouru un long chemin et, au fil de plusieurs itérations, il a également réussi à consolider son rôle en tant que langage principal.
Après avoir conquis le back-end, le monde mobile était un domaine ouvert.
C'était avec l'avènement de AJAX en 1999 (standardisé en 2006) que JavaScript a pris un second souffle. Avant AJAX, JavaScript était principalement utilisé pour animer et fournir de l'interactivité à certaines pages Web. Cependant, comme cette interactivité n'impliquerait pas l'échange de données avec le serveur, elle ne consisterait qu'à une logique d'affichage accessoire.
Avec AJAX, JavaScript a commencé à effectuer des tâches clés dans la logique applicative de nos applications Web, au point qu'il est aujourd'hui difficile de trouver des applications Web qui ne nécessitent pas un navigateur avec JavaScript activé pour fonctionner. C'est après ce changement que l'écosystème JavaScript a commencé à se développer en tant que langage de programmation côté client.
Les principaux besoins des développeurs travaillant avec des applications Web AJAX sont les suivants :
• Exécution d'appels AJAX ;
• Manipulation du modèle objet du document (DOM), la structure de données conservée par le navigateur qui représente la structure de la page Web ;
• Réagissez aux interactions de l'utilisateur.
Les fonctions JavaScript de base fournissant ces fonctionnalités n'étaient pas très pratiques et leur comportement n'était parfois pas compatible avec les différents navigateurs.
Les premières bibliothèques à devenir populaires répondaient précisément à ces trois tâches, fournissant une collection de fonctions et d'objets qui rendaient ces opérations faciles et fonctionnelles sur tous les navigateurs. Certaines de ces bibliothèques fourniraient également de nombreuses autres fonctions générales :
UNE framework JavaScript qui a été publié en 2005 dans le cadre du support AJAX de Ruby on Rails. Il a directement étendu de nombreux objets de base JavaScript avec un comportement quelque peu similaire à celui du langage de programmation Ruby, en ajoutant également un système basé sur les classes au langage.
Ces extensions de base étaient considérées comme gênantes par les autres communautés de programmation et les fonctions fournies étaient plus étranges que celles de la bibliothèque concurrente suivante :
Le Framework jQuery est sorti en 2006 et, contrairement à Prototype, a laissé le langage de base pour ainsi dire s'être concentré sur la fourniture de nombreuses fonctionnalités liées au DOM, aux événements, à l'asynchronicité et aux effets.
Une caractéristique à souligner est que jQuery prend en charge un système de plugins qui permet aux programmeurs de bibliothèques d'étendre ses fonctionnalités. Cette bibliothèque a été la bibliothèque la plus réussie de ce type, devenant l'outil indispensable pour développement front-end, utilisé de nos jours sur la plupart des sites Web.
Malgré l'immense popularité de jQuery, ainsi que sa capacité à fournir de nombreuses fonctionnalités utiles, il est important de noter que les versions modernes de JavaScript fournissent déjà de nombreuses fonctionnalités qui ont rendu jQuery populaire. Peut-être vous n'avez peut-être pas besoin de jQuery du tout.
Il est de plus en plus populaire de ne pas utiliser jQuery et de s'appuyer plutôt soit uniquement sur les fonctions JavaScript de base actuelles, soit sur des bibliothèques spécialisées dans chaque tâche spécifique (par exemple, fetch pour les appels AJAX).
Lors de l'utilisation de bibliothèques de manipulation du DOM, il est courant de conserver les données de l'application dans le DOM lui-même. Il existe donc des fonctions de sélection de manipulation du DOM qui doivent être appelées lorsque vous devez accéder à ces données ou les modifier.
Ce type de code est souvent rempli de noms de sélecteurs et devient facilement un gâchis à mesure que la complexité de l'application évolue. Il existe un ensemble de frameworks qui nous permettent d'aborder ce problème de manière élégante en nous appuyant sur des modèles d'application similaires aux célèbres Modèle Model-View-Controller (MVC).
D'autre part, il existe une tendance récente selon laquelle les applications Web sont complètement chargées dans le navigateur lors du premier chargement de la page, en effectuant toutes les opérations suivantes via AJAX.
Ce type d'applications s'appelle Application d'une seule page (SPA) et, comme leur code est souvent très élaboré et complexe, il est recommandé de choisir l'un de ces frameworks lors de la mise en œuvre d'un SPA. Examinons certains d'entre eux.
Colonne vertébrale est un framework Model-View-Presenter (MVP) publié fin 2010. Il se concentre sur les SPA et impose la séparation entre la logique d'application, la logique d'affichage et les modèles.
La communication entre ces entités est gérée de manière événementielle et prend également en charge une classe Router qui permet aux applications de réagir aux URL et de les mettre à jour en fonction des événements déclenchés.
Angulaire est un framework mis en œuvre par Google qui suivait auparavant une architecture MVC et qui a évolué vers un framework MVVC. Semblable à Backbone, il se concentre sur les SPA et impose la séparation entre la logique d'application, la logique d'affichage et les modèles.
Il est intéressant de noter qu'Angular permet au programmeur d'étendre le HTML en créant de nouvelles balises qui peuvent être utilisées dans les modèles et qui encapsulent des parties de la page.
Une autre caractéristique distinctive est qu'il permet l'établissement de liaisons de données bidirectionnelles entre les modèles et les objets JavaScript qui doivent être rendus par ceux-ci.
Ainsi, toute mise à jour de ces objets déclenchera automatiquement des mises à jour HTML et, de la même manière, les objets JavaScript seront mis à jour lorsque les champs de saisie du modèle correspondants seront modifiés.
Comme nous l'avons décrit dans les sections précédentes, la couche d'affichage de nos applications Web est passée d'un modèle informatique simple où l'interface à afficher était fonction uniquement de certaines données calculées par le code côté serveur à un modèle beaucoup plus dynamique et complexe, où cela dépendait non seulement des données récupérées mais également des interactions des utilisateurs et des scripts qui les traitaient.
Cette complexité se traduit souvent par un code complexe difficile à partager et à raisonner. Ainsi, certaines personnes de Facebook ont commencé à expérimenter un modèle informatique plus simple pour coder le front-end. Un modèle informatique qui nous permettrait de penser à nouveau à ce qui est affiché sur la page en raison de l'état de quelques variables au lieu du résultat de l'interaction entre un « zillion » de classes Model-View-Controller.
Pour que ce changement se produise, quelque chose de radical devait se produire : si nous voulions que l'affichage soit uniquement le résultat de l'application d'une fonction à certaines variables d'état, nous devrions arrêter de manipuler directement des parties du DOM et afficher chaque version de l'affichage dans son ensemble.
Comme le rendu de l'ensemble du DOM à chaque fois que vous y modifiez quelque chose serait trop lent, il a été décidé de cartographier le DOM sur une représentation légère de celui-ci, facile à régénérer et à comparer.
Ainsi, chaque fois que vous modifiez une variable, nous sommes en mesure de générer une nouvelle version de cette représentation allégée et de la comparer avec sa version précédente, calculant ainsi quelles parties du DOM doivent être mises à jour. Nous appelons Virtual DOM cette représentation légère du DOM.
Réagir a été le premier framework à utiliser un DOM virtuel. Il a été créé par Facebook et l'architecture à suivre par les applications qui l'utilisent est minimale.
En ce qui concerne MVC, React ne s'y tient pas et ne concerne que la partie View du code. Avec elle, la vue est représentée sous la forme d'un arbre d'entités appelées composants qui peuvent être eux-mêmes composés d'autres composants.
Un composant possède un certain état, peut recevoir des propriétés lors de sa création et sait comment s'afficher pour un ensemble donné de propriétés et de variables d'état. Chaque fois que son état est modifié, une nouvelle version du DOM virtuel de son écran est rendue et comparée à sa version précédente, et le DOM nécessaire est mis à jour en conséquence.
Si certaines interactions effectuées sur un composant donné doivent modifier l'état des composants parents, le composant parent doit transmettre le code de gestion au sous-composant sous la forme d'un rappel. Cette approche garantit que les composants sont mal couplés entre eux, ce qui les rend très faciles à réutiliser.
Un choix assez controversé des créateurs de ce framework est qu'au lieu d'utiliser des modèles HTML comme les autres frameworks, une représentation du code de type HTML est écrite sous forme de XHTML mélangé au code JavaScript, nécessitant ainsi l'utilisation d'un compilateur qui sait comment transformer ce mélange JS et XHTML (appelé JSX) en JavaScript générant du HTML.
L'approche basée sur les composants de React est efficace pour les petites applications, bien que pour structurer des applications plus importantes, Facebook propose une architecture appelée Flux, dans laquelle l'état de l'application est stocké loin des composants dans ce que l'on appelle des conteneurs d'état.
L'implémentation initiale de l'architecture Flux était assez complexe. mais il y en a un plus simple appelé Redux qui est la plus populaire et qui a même été utilisée pour implémenter les back-ends des applications.
Son architecture est fonctionnelle et au lieu d'une mutation directe de l'état, le programmeur est censé en créer de nouvelles versions en appliquant des fonctions de réduction, permettant ainsi d'annuler et de rétablir facilement le débogage et de voyager dans le temps.
Vue a commencé comme un framework MVC similaire à Angular, mais visant à être plus simple et nécessitant moins de passe-partout. La dernière version propose déjà une approche basée sur les composants et un Virtual-DOM de la même manière que React.
La documentation le décrit comme un cadre progressif, dans le sens où il est censé être adopté progressivement, permettant ainsi à un utilisateur de commencer par utiliser uniquement la partie vue du framework et d'ajouter ensuite plus de complexité si nécessaire. L'objectif est de réduire le nombre de fichiers standard et le nombre de fichiers utilisés dans la mesure du possible.
Lors du développement d'applications Web complexes, les utilisateurs ont remarqué que lors de la récupération de données via des appels AJAX, il y avait souvent une sous-extraction et une extraction excessive, et qu'il n'était pas facile de gérer la mise en cache.
Afin de résoudre ce problème, Facebook a développé un langage de requête qui permet de décrire les données dont chaque partie de l'interface a besoin. Ces les requêtes sont destinées à être interprétées et agrégées en ensembles efficaces de requêtes AJAX par un client GraphQL.
Au moins deux clients GraphQL sont disponibles :
• relais, l'ancienne implémentation de Facebook, étroitement liée à React ;
• Apollon, qui s'efforce d'être un projet indépendant du cadre.
Bien que JavaScript soit utilisé côté serveur depuis le milieu des années 90, ses implémentations étaient assez lentes et il n'y avait pas de réponse claire à la question de savoir comment exécuter JavaScript dans le back-end avant 2008, lorsque Google a publié le moteur JavaScript V8 intégré à la première version du navigateur Web Chrome.
Lors de la mise en œuvre de l'appelé Moteur V8, Google a utilisé des techniques d'optimisation qui avaient toutes deux été créées lors du développement de compilateurs de langages de programmation déjà oubliés, à savoir les compilateurs Self et Strongtalk. Le résultat a été remarquablement rapide pour un langage de programmation typé dynamiquement tel que JavaScript, dépassant largement les performances des autres implémentations.
D'autre part, Chrome et V8 ont tous deux été publiés en tant que logiciels open source (avec une licence BSD), permettant ainsi à quiconque de créer son travail dessus et de le distribuer dans le cadre de n'importe quel logiciel sans avoir à payer de redevances à Google.
Il n'a pas fallu longtemps pour que Ryan Dahl, un ingénieur logiciel américain, crée un environnement appelé Node.js où JavaScript pourrait être exécuté sur la version V8 à partir du navigateur. En plus d'apporter la V8 côté serveur, Node est également piloté par les événements, ce qui permet d'écrire toutes les opérations d'E/S bloquantes de manière asynchrone non bloquante.
Cette façon d'aborder les E/S associée à la rapidité du V8 a permis à Node de développer des applications en temps réel côté serveur qui nécessitaient la rapidité des E/S non bloquantes ainsi que l'expressivité d'un langage de programmation de haut niveau tel que JavaScript.
Comme la spécification de base de JavaScript est assez petite et n'est pas conçue pour le côté serveur, son utilisation pour une telle tâche nécessite généralement de nombreuses bibliothèques externes. Il est nécessaire de disposer d'un gestionnaire de packages pour Node, permettant ainsi aux développeurs de publier des packages et de récupérer facilement les bibliothèques à inclure dans les applications du développeur.
Le Gestionnaire de packages de nœuds (NPM) est un tel gestionnaire de paquets, juste dans le style du CPAN de Perl ou de RubyGems de Ruby.
Des tentatives ont été faites pour regrouper à la fois les outils et les technologies visant à créer des applications complètes. Je vais parler ici de trois de ces tentatives.
Météore est un framework Web qui utilise MongoDB comme base de données. Il utilise un protocole de publication-abonnement appliqué aux ressources, permettant aux clients d'obtenir des mises à jour lorsque les données sont mises à jour sur le serveur. Il peut être utilisé avec n'importe quel framework côté client.
Le MÉCHANTE stack représente un package doté de l'ensemble de technologies suivant :
• MongoDB ;
• Express ;
• Angulaire ;
• Nœud.
Il est également livré avec l'outil de ligne de commande « mean », qui permet de générer des projets, des fichiers et d'effectuer d'autres tâches utiles en ligne de commande.
Le MERN Stack est similaire à MEAN mais se concentre sur React plutôt que sur Angular.
Alors que JavaScript a conquis le Web, il a également fait des progrès en tant que technologie de développement d'applications mobiles. Il est souvent choisi comme moyen de gérer le mobile de manière multiplateforme.
Apache Cordova permet de développer des applications mobiles à l'aide de JavaScript, CSS et HTML. Il prend également en charge un mécanisme FFI grâce auquel les programmeurs peuvent inclure des portions de code natif et créer facilement des passerelles entre JavaScript et les fonctionnalités natives.
Bien qu'Apache Cordova permette de développer des applications mobiles avec JavaScript, il ne fournit pas les fonctionnalités de haut niveau nécessaires pour le faire. Ionic est un framework qui fournit de telles fonctionnalités : widgets, transitions d'écran et autres fonctionnalités. Il suit une architecture MVC.
React Native applique l'approche basée sur les composants de React au développement mobile, mais au lieu d'exécuter JavaScript et de lui permettre d'interagir avec le code natif, il compile plutôt le JavaScript en code natif.
Nativescript apparaît comme un autre framework populaire pour intégrer les applications Web Angular et Vue.js au monde mobile, offrant une API JavaScript homogène pour interagir avec les appareils mobiles
En tant que langue de navigateur, JavaScript a omis des instructions pour spécifier les dépendances entre les fichiers et demander au compilateur de les charger. Afin de résoudre ce problème, deux API différentes ont été spécifiées et se sont affrontées pour cette tâche :
• Définition de module asynchrone (AMD) ;
• Modules JS communs ;
• Modules ES6.
Dans le monde ES5, Node.js a implémenté des modules CommonJS alors que les programmeurs frontaux préféraient AMD, créant ainsi le chaos dans ce domaine. Il a donc été spécifié un moyen d'exiger des modules et de les déclarer appelés Définition universelle du module (UMD), ce qui est plutôt moche mais rend les modules compatibles avec les API des deux modules.
Quoi qu'il en soit, ce gâchis est atténué par l'adoption d'ES6, qui prend déjà en charge des constructions au niveau du langage visant à gérer les modules.
Lors de l'utilisation de modules lors du développement d'applications Web, il est souvent nécessaire de fusionner les différents fichiers de modules en un seul fichier à inclure dans l'application Web. Deux bibliothèques permettent aux développeurs d'effectuer cette tâche :
Browserify est le plus ancien bundle de modules Web et permet aux développeurs d'utiliser la syntaxe du module CommonJS lors de la programmation d'applications Web.
Webpack est un bundle de modules Web plus moderne qui regroupe non seulement JavaScript, mais également d'autres actifs tels que des images et du CSS. Il permet aux différents actifs d'être rechargés à chaud par le navigateur lorsqu'il y a un changement dans le code des modules.
Comme tout le monde n'est pas satisfait du langage JavaScript ou de sa prise en charge par les navigateurs, plusieurs transpileurs ont été produits qui convertissent d'autres langages de programmation en versions JavaScript compatibles avec les navigateurs. En voici quelques exemples :
Babel est un transpileur qui convertit le JavaScript moderne en JavaScript plus ancien, compatible avec les navigateurs. Il est très personnalisable et permet la compilation croisée entre plusieurs versions de JavaScript.
Assemblage Web (également connu sous le nom de wasm) est un format de bytecode désormais pris en charge par tous les principaux navigateurs comme alternative à JavaScript. Pour l'instant, il existe peu de compilateurs ciblant Web Assembly. Il convient de noter que, pour l'instant, Web Assembly ne dispose pas de ramasse-miettes.
Ainsi, lors de la compilation vers wasm, il faut soit utiliser un langage de programmation qui ne nécessite aucun ramasse-miettes, soit compiler un environnement d'exécution qui permet la collecte des déchets avec l'application/le module restant.
Ce transpileur, créé par Microsoft, convertit un sur-ensemble typé progressif de JavaScript appelé Tapez Script en JavaScript.
Flow est un vérificateur de type statique développé par Facebook. Comme Typescript, il s'agit d'un système typé progressif, bien que Flow se concentre uniquement sur les types et n'ajoute rien d'autre au langage que le système de types.
Orme est un cadre et un langage de programmation fonctionnel purement typé inspiré de Haskell qui compile en JavaScript et suit la même architecture que Redux, qui est fortement inspiré d'Elm.
Contrairement à d'autres systèmes de types statiques, celui-ci garantit une couverture de type à 100 % grâce à l'inférence de type, évitant ainsi au programmeur de saisir explicitement une signature de type. Le système de types est si sûr qu'il ne permet aucune exception d'exécution.
C'est la façon dont Facebook utilise un langage de programmation fonctionnel typé pour générer du JavaScript. ReasonML utilise la sémantique O'Caml et une syntaxe basée sur les accolades adaptée à JavaScript. Il peut être considéré comme un cousin d'Elm qui n'aime pas tellement la pureté fonctionnelle et qui est soutenu par Facebook.
À mesure que les projets prennent de l'ampleur et qu'il est nécessaire de transformer leurs actifs pour les exécuter, il est nécessaire d'écrire des scripts qui gèrent l'exécution de ces transformations, comme make, ant ou rake. Deux exécuteurs de tâches basés sur les dépendances sont implémentés en JavaScript :
Un plus ancien appelé grognement - dans lequel les données intermédiaires aux différentes étapes de transformation sont conservées dans des fichiers temporaires. Et Gorgée - qui est une version plus récente qui utilise plutôt la mémoire que les fichiers temporaires.
JavaScript étant un langage issu du navigateur, pourquoi ne pas l'utiliser pour développer le côté serveur de nos applications Web ? Express est le cadre qui aborde ce problème. Il vise à être minimaliste (comme Sinatra), bien que de nombreuses grandes bibliothèques aient été développées pour cela (par exemple, la génération automatique de backoffice).
Comme la V8 a été utilisée pour créer Node, elle a également été utilisée comme interpréteur par la base de données orientée document MongoDB. Lors de l'interaction avec la base de données, les données sont partagées dans des structures de type JSON et le langage de requête consiste à invoquer des fonctions JavaScript. Cela rend cette base de données très populaire auprès des développeurs JavaScript.
Yeoman est un générateur de squelette de projet interactif écrit en JavaScript. Il permet de créer de nombreux types de projets JavaScript avec différentes configurations. Bien qu'il ne soit pas uniquement destiné à JavaScript, il peut également être utilisé pour générer des squelettes de projets Java, par exemple.
Développeur de rails avec plus de 10 ans d'expérience dans diverses technologies. Je m'intéresse à la programmation fonctionnelle.
People who read this post, also found these interesting:
.webp)
.webp)
%20(2).webp)
