Ce que la proposition de syntaxe de type ES de Microsoft signifie pour JavaScript

0
120

JavaScript pourrait bientôt avoir sa propre syntaxe de type si une proposition soumise par Microsoft et d'autres développeurs plus tôt cette année devient une partie de la norme ECMAScript. L'initiative prévoit d'ajouter des “types en tant que commentaires” prise en charge du langage JavaScript, permettant aux développeurs d'annoter le code avec des informations de type qui seront utilisées par d'autres composants de l'écosystème.

La syntaxe

La proposition la syntaxe ressemble à ceci :

fonction sayAge(nom : chaîne, âge : nombre) { console.log(`${nom} a ${âge} ans.`); }   sayAge("JavaScript", 26);

Il sera familier à tous ceux qui ont déjà utilisé TypeScript, le sur-ensemble typé de JavaScript de Microsoft. TypeScript a été largement adopté dans l'industrie ; cette nouvelle proposition prétend apporter certains de ses avantages au monde JavaScript au sens large.

Quelle n'est pas la proposition ?

Si elle est approuvée, cette proposition vous permettra d'écrire du JavaScript parfaitement valide avec les annotations de type indiquées ci-dessus. Il sera accepté par les environnements d'exécution JavaScript tels que les navigateurs Web, Node.js et Deno qui respectent la norme ES.

Cependant, la proposition n'étend pas réellement le langage JavaScript. Vos annotations de type seront exactement cela : des métadonnées inertes qui n'ont aucun effet sur le compilateur JavaScript ou l'exécution de votre code. Un appel de fonction tel que le suivant fonctionnerait lors de l'exécution :

fonction sayAge(nom : chaîne, âge : nombre) { console.log(`${nom} a ${âge} ans.`); }   //"âge" est une chaîne alors qu'il devrait s'agir d'un nombre, mais cela est toujours autorisé sayAge("JavaScript", "twenty");

L'idée est d'offrir une nouvelle syntaxe de type qui est officiellement prise en charge mais complètement ignorée par les moteurs. Le seul changement pour les implémentations concerne la reconnaissance et la suppression des annotations de type partout où elles sont utilisées.

La proposition chercherait à établir un support annotant les types de paramètres, de variables et de propriétés de classe. Il envisagerait également d'ajouter un mot-clé d'interface, des opérateurs d'assertion comme ! et comme, et un ? modificateur pour marquer les types comme facultatifs. L'intention est que tous ces éléments reflètent TypeScript ; comme pour toute proposition de l'étape 0, le résultat final peut cependant fonctionner différemment.

Quel est le point ?

Si les annotations de type ne changent pas votre programme, la question évidente est de savoir si elles en valent la peine. La proposition soutient “oui” en raison de la capacité de la syntaxe à raccourcir les temps d'itération et à réduire la charge autour des chaînes d'outils JavaScript modernes.

L'écriture de code de type sécurisé nécessite actuellement l'utilisation de TypeScript, une version de langage différente qui ajoute des dépendances à votre projet et nécessite une étape de compilation manuelle. Ce code peut ensuite passer par d'autres outils tels qu'un module bundler et transpiler avant que votre JavaScript final ne soit produit pour distribution. Il s'ajoute à une chaîne d'outils complexe avec plusieurs parties mobiles.

Bien que JavaScript soit un langage intrinsèquement faiblement typé, les avantages d'un typage fort sont désormais largement reconnus par la communauté. Cela ressort clairement de l'élan entourant le projet TypeScript. Le typage statique était également le leader incontesté de la « fonctionnalité manquante » de l'enquête State of JS de 2021 ; questions.

L'ajout d'une syntaxe de type à JavaScript lui-même vous permettrait de bénéficier de certains des avantages de TypeScript sans avoir à compiler votre code. Cela simplifie la configuration et la maintenance du projet tout en faisant évoluer JavaScript pour mieux s'aligner sur les pratiques de développement modernes.

Au cours des dernières années, davantage de code a commencé à migrer vers un “JavaScript pur” approcher. Le déclin des anciens navigateurs rend la transpilation moins nécessaire qu'elle ne l'était autrefois – la majorité des implémentations modernes offrent une prise en charge complète des fonctionnalités telles que les classes, les fonctions fléchées, les variables à portée de bloc et async/wait. JavaScript a même un système de modules à part entière qui fonctionne sur tous les moteurs, y compris dans les navigateurs.

Il y a quelques années seulement, une longue chaîne d'outils était nécessaire pour pouvoir écrire ces fonctionnalités dans votre code avec confiance que cela fonctionnerait sur les utilisateurs & #8217; dispositifs. De nos jours, les développeurs peuvent mettre ces processus de construction de côté en toute sécurité, en revenant au modèle JavaScript original de référencement de fichiers avec <script> balises.

Les types sont l'un des rares domaines restants de l'écosystème JavaScript qui ne sont pas pris en charge par le langage lui-même. Aimez-les ou détestez-les, il est indéniable que les types font désormais partie intégrante du développement JavaScript pour de nombreuses équipes et projets. La proposition de syntaxe reconnaît formellement ce fait. Il tente d'apporter un certain degré de prise en charge des types à JavaScript sans casser le code existant ni appliquer des vérifications de type d'exécution qui nuisent aux performances.

Que devraient réellement faire les types ?

Le rôle d'un “type” varie selon les langues. Le démoninateur commun réside dans la capacité d'un type à exprimer le type de données qu'une variable particulière contiendra. Des significations, des capacités et des comportements supplémentaires sont ensuite superposés sur cette base.

Dans les langages compilés typés statiquement comme C# et Java, les types sont appliqués au moment de la compilation. Il est impossible de compiler un programme lorsque vous avez des incompatibilités de type dans votre code. Dans les langages interprétés avec un typage fort facultatif, dont PHP est un exemple, les types sont appliqués au moment de l'exécution – le programme génère une erreur lorsque le type d'une valeur est incompatible avec le contexte dans lequel elle est utilisée.

Un débat actif au sein de la communauté JavaScript a été de savoir jusqu'où les attributions de tout système de type intégré devraient s'étendre. Cette proposition limite son rôle à l'élément le plus fondamental, une simple documentation du type attendu d'une valeur. Cela correspond bien à la position de TypeScript en tant que syntaxe de type effaçable qui est ignorée lors de l'exécution.

Le but de ce modèle est de donner aux développeurs un retour instantané sur les bogues potentiels lorsqu'ils écrivent du code. Vous pouvez obtenir des informations sur les problèmes de type lorsque vous écrivez du JavaScript normal dans un IDE compatible. Si vous le souhaitez, vous pouvez également utiliser un outil de support tel que TypeScript, un analyseur statique ou un bundler pour auditer votre source à la demande. Cela pourrait bloquer un déploiement dans vos pipelines CI lorsqu'un problème de type est présent.

Le sentiment actuel est que ces capacités sont suffisantes pour aligner JavaScript sur les besoins les plus courants des développeurs. Les fonctionnalités trouvées dans d'autres langages, telles que l'introspection et la réflexion, ne sont généralement pas nécessaires dans l'écosystème JavaScript, en partie parce que les développeurs se sont habitués à l'approche d'effacement de TypeScript.

L'alternative existante : Docblocks

Il convient de noter qu'il existe déjà quelque chose de similaire à la syntaxe proposée pour les annotations effacées : les balises JSDoc familières sont couramment utilisées pour ajouter des détails de type au code JavaScript :

/** * @param name {string} * @ param age {nombre} */function sayAge(nom, age) { console.log(`${nom} a ${âge} ans.`); }

Les commentaires JSDoc sont pris en charge par divers outils populaires. Cependant, ils ne font pas partie intégrante du langage et vous obligent à mélanger les détails du fonctionnement de votre code – ses types attendus – avec la documentation centrée sur l'humain comprenant le reste du docblock.

La syntaxe de JSDoc est également très détaillée. Outre les noms de balises requis, cela nécessite généralement la répétition d'éléments déjà existants dans votre code, tels que les noms de paramètres dans l'exemple ci-dessus. Si vous modifiez un paramètre dans la signature de la fonction, n'oubliez pas de modifier également la balise JSDoc.

La nouvelle proposition de syntaxe peut être fonctionnellement équivalente à docblocks mais elle offre une expérience beaucoup plus simplifiée. Les types se trouvent à côté de leurs cibles dans le cadre de votre source, plutôt que dans un docblock que vous devez créer et gérer séparément.

Et ensuite ?

L'équipe TypeScript de Microsoft et ses co-auteurs, dont Bloomberg, Igwalia et plusieurs contributeurs indépendants, ont soumis la proposition de l'étape 0 lors de la plénière du TC39 de mars 2022. La proposition est depuis passée à l'étape 1. L'acceptation est encore loin, la mise en œuvre dans les moteurs n'arrivera peut-être pas avant “des années”.

L'objectif primordial de cette proposition est de équilibrer la longue queue de code non typé de JavaScript avec la demande actuelle d'une expérience de développement plus typée statiquement. L'utilisation d'une syntaxe entièrement facultative effacée garantit la rétrocompatibilité, mais laisse craindre qu'elle ne soit pas efficace pour encourager l'adoption et consolider l'écosystème. Le débat autour de celui-ci devrait se développer avec de nouvelles opinions et perspectives à mesure que la proposition progresse dans la voie des normes.

LIRE LA SUITE

  • › Comment débloquer Spotify
  • &rsaquo ; La mise à jour 2022 de Windows 11 est là, bientôt les onglets de l'explorateur de fichiers
  • › Comment vérifier la version de PowerShell sous Windows 11
  • › Comment installer la mise à jour 2022 de Windows 11 (22H2)
  • › Comment prendre des instantanés dans VLC
  • &rsaquo ; Comment mettre à jour PowerShell sur Windows 11