Microsoft, Igalia et Bloomberg proposent d'inclure une syntaxe pour la définition en JS 

Microsoft, Igalia et Bloomberg Ils ont annoncé il y a quelques jours que ont pris l'initiative d'inclure une syntaxe pour la définition de type explicite dans la spécification JavaScript, similaire à la syntaxe utilisée dans le langage TypeScript.

Actuellement, les modifications du prototype proposées pour inclusion dans la norme ECMAScript ont été soumises pour des discussions préliminaires (étape 0).

Aujourd'hui, nous sommes heureux d'annoncer notre soutien et notre collaboration sur une nouvelle proposition de l'étape 0 pour apporter une syntaxe de type facultative et effaçable à JavaScript. Parce que cette nouvelle syntaxe ne changerait pas la façon dont le code environnant est exécuté, ils agiraient effectivement comme des commentaires. Nous pensons que cela a le potentiel de rendre TypeScript plus facile et plus rapide à utiliser pour le développement à toutes les échelles. Nous aimerions expliquer pourquoi nous poursuivons cela et comment cette proposition fonctionne à un niveau élevé.

Il est mentionné qu'à tAvoir des informations de type explicites évitera de nombreuses erreurs dans le processus de développement, cela offrira la possibilité d'utiliser des techniques d'optimisation supplémentaires, de simplifier le débogage et de rendre le code plus lisible et plus facile à modifier et à entretenir pour les développeurs tiers.

En plus que il est proposé d'implémenter le support de type en tant que fonction optionnelle : Les moteurs JavaScript et les runtimes qui ne prennent pas en charge la vérification de type ignoreront les annotations avec des informations de type et traiteront le code comme avant, percevant les données de type comme des commentaires. Mais les outils de vérification de type pourront, sur la base des informations disponibles, détecter les erreurs liées à une mauvaise utilisation des types.

fond
Une tendance récente que notre équipe a constatée dans le monde JavaScript est la demande d'un temps d'itération plus rapide et d'étapes de construction réduites. En d'autres termes, "rendez-le plus rapide et plus simple".

D'une certaine manière, cela se produit déjà. Grâce au succès des navigateurs à feuilles persistantes, les développeurs peuvent souvent éviter de compiler de nouvelles versions de JavaScript pour s'exécuter sur des environnements d'exécution plus anciens. Dans une certaine mesure, il en va de même pour le groupement : la plupart des navigateurs ont un support intégré pour l'utilisation de modules, de sorte que le groupement peut être considéré plus comme une étape d'optimisation que comme une nécessité. Cela a de plus en plus été le cas, alors comment TypeScript résiste-t-il ?

En même temps, contrairement aux informations de type spécifiées via des annotations JSDoc spécifiées en commentaires, la spécification directe des types directement dans les constructions de définition de variable cela rendra le code plus visuel, compréhensible et plus facile à modifier.

Par exemple, les IDE compatibles TypeScript pourront immédiatement mettre en évidence les erreurs dans le code JavaScript écrit sans transformations supplémentaires. De plus, la prise en charge intégrée des types permettra d'exécuter des programmes écrits dans des dialectes JavaScript scriptés tels que TypeScript et Flow sans transpiler d'un langage à un autre.

Parmi les types, il est proposé d'ajouter "string", "number" et "boolean", qui peuvent être utilisés lors de la définition de variables, de paramètres de fonction, d'éléments d'objet, de champs de classe, de tableaux typés ("number[]"). Il est également proposé de prendre en charge les types mixtes ("string | number") et les génériques.

Compte tenu de tout cela, nous prévoyons de présenter cette proposition pour l'étape 1 lors de la prochaine réunion plénière du TC2022 de mars 39. Nous le ferons avec le soutien et les conseils de nos co-champions de cette proposition, Rob Palmer chez Bloomberg et Romulo Cintra chez Igalia.

Atteindre l'étape 1 signifierait que le comité des normes estime qu'une syntaxe de type compatible pour ECMAScript mérite d'être envisagée. Ce n'est pas sûr : il y a beaucoup de points de vue intéressants au sein du comité, et nous nous attendons à un certain scepticisme. Une proposition comme celle-ci recevra beaucoup de commentaires et un examen minutieux. Cela peut impliquer de nombreux changements de conception en cours de route et cela peut prendre des années pour obtenir des résultats.

à la prochaine réunion de mars du comité TC39, il est prévu de passer à la première étape examen de la proposition avec la participation de la communauté d'experts de l'ECMA.

Enfin Si vous souhaitez en savoir plus, vous pouvez vérifier les détails dans le lien suivant


Soyez le premier à commenter

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont marqués avec *

*

*

  1. Responsable des données: Miguel Ángel Gatón
  2. Finalité des données: Contrôle du SPAM, gestion des commentaires.
  3. Légitimation: votre consentement
  4. Communication des données: Les données ne seront pas communiquées à des tiers sauf obligation légale.
  5. Stockage des données: base de données hébergée par Occentus Networks (EU)
  6. Droits: à tout moment, vous pouvez limiter, récupérer et supprimer vos informations.