Débat dans la communauté JavaScript sur la syntaxe des types proposés – The New Stack

by

Si une proposition dévoilée cette semaine fait son chemin, les développeurs JavaScript auront bientôt quelque chose que beaucoup d’entre eux demandent depuis longtemps : un système de type, d’une certaine sorte au moins.

Un article de blog du responsable principal du programme TypeScript, Daniel Rosenwasser, présente le contexte et le raisonnement de la proposition de syntaxe de type en JavaScript. Il écrit que “si nous réussissons tout cela, nous avons la chance d’apporter l’une des améliorations les plus percutantes au monde de JavaScript”.

La proposition, qui partage des auteurs de Microsoft, Bloomberg, Igalia et un certain nombre d’autres sources, suggère que les développeurs JavaScript devraient pouvoir “ajouter des annotations de type à leur code JavaScript, permettant à ces annotations d’être vérifiées par un vérificateur de type externe”. à JavaScript” et ensuite être ignoré lors de l’exécution.

“Parce que cette nouvelle syntaxe ne changerait pas la façon dont le code environnant s’exécute, elle agirait effectivement comme des commentaires”, écrit Rosenwasser dans son article de blog, ajoutant plus tard que “JavaScript pourrait créer un ensemble de syntaxe pour les types que les moteurs ignoreraient entièrement, mais quels outils comme TypeScript, Flow et autres pourraient utiliser. Cela nous permet de conserver les choses que vous aimez à propos de TypeScript – son expérience de vérification de type et d’édition – tout en supprimant le besoin d’une étape de construction dans le développement.

Jusqu’à présent, les types étaient relégués à TypeScript en partie parce que cette étape de construction pouvait également être utilisée pour compiler du code pour les différents navigateurs. Cependant, avec l’avènement de navigateurs à feuilles persistantes mis à jour en permanence, les auteurs de la proposition écrivent qu’ils “prévoient que les développeurs auront moins besoin de compiler à un niveau inférieur” et donc, “pour de nombreux utilisateurs de TypeScript, la seule étape nécessaire entre l’écriture du code et son exécution. sera d’effacer les annotations de type.

Une partie remarquable de la proposition énonce exactement ce qui n’est pas proposé :

“Notre équipe ne propose pas de mettre la vérification de type de TypeScript dans chaque navigateur et runtime JavaScript – nous ne proposons pas non plus de nouveau vérificateur de type à mettre dans le navigateur. Nous pensons que cela causerait des problèmes aux utilisateurs de JavaScript et de TypeScript en raison d’une série de problèmes, tels que les performances d’exécution, les problèmes de compatibilité avec le code TypeScript existant et le risque d’arrêter l’innovation dans l’espace de vérification de type.

De même, plusieurs fonctionnalités de TypeScript qui génèrent du code, telles que les énumérations, les espaces de noms et les propriétés des paramètres, sont explicitement exclues “parce qu’elles ont une sémantique d’exécution, générant du code JavaScript plutôt que d’être simplement supprimées et ignorées”.

Comme vous vous en doutez, l’ajout potentiel de types à JavaScript – même ceux qui sont complètement facultatifs – n’est pas quelque chose sur lequel absolument tout le monde est d’accord.

Pour de nombreux détracteurs, l’argument est que l’ajout de types en tant que commentaires compliquera inutilement le code visuellement et le rendra plus difficile pour les nouveaux développeurs. Ils soutiennent également que, moins le code souffre de ballonnement, une étape supplémentaire sera de toute façon nécessaire pour supprimer ce code. D’autres soutiennent encore qu’il y a une raison pour laquelle TypeScript est TypeScript, et non JavaScript, mais ils oublient peut-être que cette proposition exclut intentionnellement un certain nombre de fonctionnalités TypeScript.

“Cette proposition est un exercice d’équilibre : essayer d’être aussi compatible avec TypeScript que possible tout en autorisant d’autres systèmes de typage, et en n’entravant pas trop l’évolution de la syntaxe de JavaScript”, propose la proposition sur ce point.

Comme le notent les auteurs de la proposition, la proposition elle-même est présentée comme une “proposition de paille” et, en tant que telle, destinée à déclencher précisément ce type de débat animé. Jusqu’à présent, il semblerait qu’il y ait de nombreux débats, parallèlement à un enthousiasme plutôt robuste pour l’avènement de la fonctionnalité de type à venir dans un JavaScript près de chez vous.

Cette semaine en programmation

  • Liste des mentors Summer of Code Drops de Google : Pour ceux d’entre vous qui envisagent de postuler au Google Summer of Code (GSoC) 2022, la liste des organisations de mentorat a été révélée. Il ajoute 32 nouvelles organisations, pour porter le total à 203 projets open source. Les organisations comprennent une variété de fondations – la Linux Foundation, la Cloud Native Computing Foundation, la Eclipse Foundation, la Python Software Foundation, pour n’en nommer que quelques-unes – et des projets open source comme TensorFlow, GitLab, Jenkins, Dart, Ruby, Julia et beaucoup plus. Le GSoC se déroule chaque été (hémisphère nord), encadrant les développeurs dans la manière de contribuer aux logiciels open source. Les candidatures ouvrent le lundi 4 avril et se terminent le mardi 19 avril.
  • Les retombées dramatiques de DHH continuent : La semaine dernière, nous avons raconté comment le créateur de Ruby on Rails, DHH et RailsConf, se sont séparés après que l’équipe de RailsConf lui ait demandé de partager la scène du discours d’ouverture, et cette semaine, les retombées se sont poursuivies, alors que le membre de l’équipe principale de Rails, Kasper Timm Hansen, était plutôt abrupt. a quitté l’équipe de base. Hansen avait signalé son mécontentement face à la situation une semaine plus tôt, lorsqu’il tweeté qu’il préférait ne pas être mentionné dans les articles de blog de DHH, et peu de temps après, il a émis la demande d’extraction qui indiquait simplement “Je quitte le noyau de Rails et je ne suis pas intéressé à faire partie des anciens.” Il y a eu beaucoup de fanfare lorsque Kasper a rejoint le noyau de Rails et, si les réponses à ses tweets et demandes d’extraction sont une indication, le onzième contributeur le plus productif de Rails semble manquer à la communauté dans son ensemble.
  • Le développement de logiciels embarqués arrive dans VS Code : Suite à un lancement similaire pour Visual Studio 2022, Microsoft a publié l’extension Embedded Tools pour Visual Studio Code, qui, selon la description de l’extension « fournit une visionneuse de registre pour les fichiers CMSIS-SVD et une visionneuse de données RTOS avec prise en charge d’Azure RTOS et FreeRTOS. » L’extension, utilisée parallèlement aux nouvelles fonctionnalités d’artefact vcpkg qui aide à acquérir des dépendances d’outils intégrés, permet aux développeurs de démarrer rapidement une machine de développement intégrée et de démarrer. Avec l’ajout de cette extension, VS Code offre désormais aux développeurs toutes les fonctionnalités habituelles, y compris la navigation dans le code, IntelliSense, la construction, le déploiement, le débogage et de nouvelles capacités de diagnostic autour des registres périphériques et des vues d’objets du système d’exploitation en temps réel (RTOS).

Leave a Comment