SWC se concentre, comme Babel, sur la génération de code JavaScript compatible et même sur le bundling, tandis qu’ici l’accent est mis sur la transformation du code TypeScript en JavaScript ou sur la vérification des erreurs.
Quand j’écris du code simple mais difficile à retenir par cœur (gestion des entrées/sorties de fichiers, manipulation de conteneurs, etc.)
Quand une erreur de compilation ou d’exécution se produit, pour comprendre de quel type d’erreur il s’agit et quelle partie du code en est la cause
Quand je veux réécrire une fonction proche d’une fonction déjà écrite, mais avec une fonctionnalité légèrement différente
Quand je veux remplacer un code qui dépend d’une bibliothèque donnée par une autre bibliothèque ou par une fonction maison
Quand j’ai besoin d’un guide sur la manière de développer pour implémenter une fonctionnalité précise ou travailler dans un environnement particulier
Dans ce genre de cas, j’ai gagné pas mal de temps. Avec la combinaison Google + Stack Overflow, on ne trouve souvent pas grand-chose de pertinent, et surtout sur Stack Overflow, même quand il y a une réponse, il y a toujours beaucoup d’objections en commentaires, ou bien il s’agit d’une manière de faire d’une ancienne version qu’il ne faut plus utiliser, ce qui était souvent vraiment agaçant...
Si on découpe en périodes de 1 à 2 semaines, il me semble qu’assez naturellement seule une partie limitée des personnes connaîtra la vision d’une fonctionnalité donnée. Un peu comme la différence entre un processus et un thread. L’idée est d’accroître la productivité en limitant le champ d’attention.
Même si cette vision est partagée, cela suppose qu’on la questionnera, mais je me rends compte que j’ai aussi naturellement posé comme hypothèse qu’on n’arrive pas à suivre la vue d’ensemble en fonction d’une orientation qui change un peu à chaque sprint planning.
Lorsqu’on découpe ainsi le travail en petites tâches, le leader qui a la vision d’ensemble se retrouve avec un pouvoir important. Les ingénieurs qui travaillent avec lui en viennent plutôt à perdre leur motivation et à se demander : « Au juste, vers quoi est-ce qu’on va ? » C’est un défaut typique de l’agile basé sur les sprints.
On a l’impression que c’est écrit de manière trop centrée sur le point de vue du leader, comme l’indique le titre.
L’élan des ingénieurs est aussi fortement influencé par la direction dans laquelle le leader brandit le drapeau. Il semble qu’il faudrait aussi réfléchir davantage à la manière de formuler clairement la valeur qu’on veut apporter au client, ainsi que l’output de chaque sprint et l’outcome de livraison. Bien sûr, ce sont des soft skills difficiles, il est rare de voir des leaders qui les maîtrisent vraiment, et il n’existe pas beaucoup de textes à ce sujet non plus.
Je comprends pour .NET, mais j’ai l’impression que Rust se situe au même niveau que Go. J’imagine que les projets et bibliothèques Go déjà existants autour de JS ont aussi influencé la décision.
C’est vraiment une idée très originale, mais comme les autres commentaires, je me demande aussi comment ils comptent résoudre le problème d’un afflux massif de trafic.
> Si le code TypeScript n’est plus écrit en TypeScript, l’équipe cessera de l’utiliser directement, ce qui pourrait affecter à long terme l’expérience de développement.
On parle de dogfooding, le fait d’utiliser soi-même ce qu’on a créé. Mais dans le cas d’un langage, ça me fait un peu réfléchir.
Cela dit, quand on veut adopter les technologies les plus récentes (?), il arrive assez souvent que JUnit4 soit un frein, donc personnellement j’ai le petit espoir qu’on migre vers JUnit5. https://docs.gradle.com/develocity/test-distribution/
On peut faire fonctionner des tests JUnit4 sur JUnit5 sans gros changements en utilisant junit-vintage-engine, mais le surcoût est assez important. (environ 20 % plus lent)
Il n’y a pas d’informations sur les performances en coréen, mais après quelques essais, ça n’a pas l’air mauvais.
S’il est doté de fonctionnalités pour contourner les protections anti-bot, il pourrait bien devenir le gagnant du marché.
La controverse semble assez vive pour qu’Anders Hejlsberg ait laissé lui-même un commentaire.
https://github.com/microsoft/typescript-go/…
Oui, c’est bien ça !
Une personne aimerait compiler du TypeScript pour obtenir directement un binaire en sortie
Merci de présenter ces bonnes ressources.
SWC se concentre, comme Babel, sur la génération de code JavaScript compatible et même sur le bundling, tandis qu’ici l’accent est mis sur la transformation du code TypeScript en JavaScript ou sur la vérification des erreurs.
Cela correspond assez à mon expérience aussi.
Dans ce genre de cas, j’ai gagné pas mal de temps. Avec la combinaison Google + Stack Overflow, on ne trouve souvent pas grand-chose de pertinent, et surtout sur Stack Overflow, même quand il y a une réponse, il y a toujours beaucoup d’objections en commentaires, ou bien il s’agit d’une manière de faire d’une ancienne version qu’il ne faut plus utiliser, ce qui était souvent vraiment agaçant...
Si on découpe en périodes de 1 à 2 semaines, il me semble qu’assez naturellement seule une partie limitée des personnes connaîtra la vision d’une fonctionnalité donnée. Un peu comme la différence entre un processus et un thread. L’idée est d’accroître la productivité en limitant le champ d’attention.
Même si cette vision est partagée, cela suppose qu’on la questionnera, mais je me rends compte que j’ai aussi naturellement posé comme hypothèse qu’on n’arrive pas à suivre la vue d’ensemble en fonction d’une orientation qui change un peu à chaque sprint planning.
Ne s’agit-il pas de partager la vision d’ensemble, puis de découper le travail en petites tâches une fois que tout le monde l’a bien comprise ?
Merci pour cet excellent article.
Lorsqu’on découpe ainsi le travail en petites tâches, le leader qui a la vision d’ensemble se retrouve avec un pouvoir important. Les ingénieurs qui travaillent avec lui en viennent plutôt à perdre leur motivation et à se demander : « Au juste, vers quoi est-ce qu’on va ? » C’est un défaut typique de l’agile basé sur les sprints.
On a l’impression que c’est écrit de manière trop centrée sur le point de vue du leader, comme l’indique le titre.
L’élan des ingénieurs est aussi fortement influencé par la direction dans laquelle le leader brandit le drapeau. Il semble qu’il faudrait aussi réfléchir davantage à la manière de formuler clairement la valeur qu’on veut apporter au client, ainsi que l’output de chaque sprint et l’outcome de livraison. Bien sûr, ce sont des soft skills difficiles, il est rare de voir des leaders qui les maîtrisent vraiment, et il n’existe pas beaucoup de textes à ce sujet non plus.
Je ne connais pas grand-chose au front... c’est différent de swc ?
Il est 8 h 40 du matin en ce moment, et en regardant distraitement, je vois qu’il est exactement 7:40:28 PM EST... c’est fascinant.
Une visite chez McDonald’s semble facile. Cela a l’air d’être une expérience amusante.
Je comprends pour .NET, mais j’ai l’impression que Rust se situe au même niveau que Go. J’imagine que les projets et bibliothèques Go déjà existants autour de JS ont aussi influencé la décision.
C’est vraiment une idée très originale, mais comme les autres commentaires, je me demande aussi comment ils comptent résoudre le problème d’un afflux massif de trafic.
Vous semblez parler de runtimes comme Node, mais ici il s’agit du compilateur du langage TS lui-même.
> Si le code TypeScript n’est plus écrit en TypeScript, l’équipe cessera de l’utiliser directement, ce qui pourrait affecter à long terme l’expérience de développement.
On parle de dogfooding, le fait d’utiliser soi-même ce qu’on a créé. Mais dans le cas d’un langage, ça me fait un peu réfléchir.
Cela dit, quand on veut adopter les technologies les plus récentes (?), il arrive assez souvent que JUnit4 soit un frein, donc personnellement j’ai le petit espoir qu’on migre vers JUnit5.
https://docs.gradle.com/develocity/test-distribution/
On peut faire fonctionner des tests JUnit4 sur JUnit5 sans gros changements en utilisant
junit-vintage-engine, mais le surcoût est assez important. (environ 20 % plus lent)