Discussion :

[LSMetag]

Il y a aussi une implémentation de Yeoman Generator : https://www.npmjs.com/package/generator-typings

[tmcuh]

En même temps les professionnel windows application publie très peu leur code contrairement au web ou le fait de partager est presque un devoir pour corriger les bugs et stabiliser la multitude de technologie qui existe. Les mecs du web sont enfermé de carcan en carcan et n'ont pas d'autres choix que de partager.

[sekaijin]

Ha !?

C'est nouveau ça ce n'est pas ce que je constate depuis 1994 que je travaille dans le monde du web.

[duplaisir111]

Vu la communauté derrière Angular, on pouvait bien s'y attendre.
De plus après avoir parcouru l'essentiel de TypeScript je me suis bien rendu compte qu'il facilite l'écriture, la lecture, et la compréhension du code, bref de quoi retrouver les joies de la POO.
Je compte bien l'adopter.....

[SurferIX]

A chaque fois que je vois Python autant devant Php, ça me conforte dans ma décision de laisser tomber définitivement Php au profit de Python.

[SylvainPV]

Je pilote les devs d'un projet Angular 2 depuis le début de l'année avec une équipe de 4-5 personnes. Etant très méfiant vis à vis de l'avenir de TypeScript (par rapport à Dart, CoffeeScript et tous ses prédécesseurs enterrés), j'ai choisi de rester sur Babel avec quelques presets se rapprochant de la syntaxe TypeScript (types, annotations, décorateurs, propriétés de classes...). C'est une sorte d'intermédiaire entre Flow et TypeScript, qui me donnait une porte de sortie (au cas où) tout en pouvant utiliser la documentation TS pour Angular.

Mes collègues ont un meilleur niveau en Java qu'en JS à la base, ils ont donc bien accueilli les ressemblances entre TS et Java, ayant l'impression de se retrouver dans un environnement familier. On a mis en place une code review systématique et j'ai pu observer de près leur montée en compétences.

Après ces quelques mois, voilà le bilan: le langage est apprécié par l'équipe (le framework beaucoup moins mais c'est une autre histoire) ; le typage statique s'avère utile, davantage dans son rôle d'auto-documentation du code plutôt que de prévention de bugs. La norme ES6 est une bénédiction tant elle simplifie radicalement le code un peu partout.

Le bilan est donc globalement positif, mais il y a quand même quelque-chose qui me gène: j'ai l'impression qu'en apprenant ce TypeScript-like, mes collègues en viennent à désapprendre le JS. Ils utilisent désormais presque exclusivement des classes, quitte à en déclarer beaucoup trop qui ne servent qu'une fois alors que des objets littéraux feraient parfaitement l'affaire. On a également beaucoup d'héritage avec class extends, alors que je m'étais juré de favoriser la composition et de limiter les hiérarchies d'objets. Et j'ai beau encourager un style de programmation fonctionnelle, la codebase actuelle est très orientée OOP classique avec beaucoup d'objets mutables et un usage omniprésent de this. Bref j'ai l'impression de bosser sur un projet Java / C#, et ça ne me plaît pas beaucoup. Vous connaissez le proverbe "Quand on a qu'un marteau, tout ressemble à un clou" ? Eh bien c'est à peu près ce qui se passe ici selon moi: toutes les nouveautés TS sont utilisées abusivement et le JS vanilla semble délaissé.

J'en conclus que TypeScript va beaucoup diviser les opinions des développeurs selon leur background. Je pense que le typage fort n'est plus le fer de lance de TypeScript, contrairement à ce que son nom pourrait laisser croire. Une majorité des devs accepte l'idée qu'un typage fort optionnel est bénéfique, mais TS est loin d'être la seule option pour ça: Flow, Elm, Kotlin, ObjectModel (celui-là est de moi ^^). Non, s'il faut caractériser TypeScript, c'est surtout l'expérience de développement familière aux devs Java et C# qui va sans doute séduire les uns et repousser les autres.

[yahiko]

Dans la mesure où, si j'ai bien compris, ce que tu as mis en place n'est pas vraiment TypeScript, mais un erzatz, je reste un peu sceptique quant à la portée de ton retour d'expérience.
Il serait plus honnête dans le sens plus transparent si tu partageais plus en détails tes presets Babel pour juger de la réelle proximité avec le compilateur TypeScript.

[Songbird]

Salut,

Mes collègues ont un meilleur niveau en Java qu'en JS à la base, ils ont donc bien accueilli les ressemblances entre TS et Java, ayant l'impression de se retrouver dans un environnement familier. On a mis en place une code review systématique et j'ai pu observer de près leur montée en compétences.

En dehors des classes, je ne vois pas trop ce que les développeurs Java ont de familier avec TS, sachant qu'il est possible de mélanger de la programmation procédurale et OO, alors qu'en Java non, et le typage y est très faible, par rapport à java. (même le système d'imports n'a rien de familier, à mon goût)

En revanche Dart ressemblerait plus à un Java-like, mais il en reste loin. (encore heureux, dans un sens)

[yahiko]

Etant très méfiant vis à vis de l'avenir de TypeScript (par rapport à Dart, CoffeeScript et tous ses prédécesseurs enterrés), j'ai choisi de rester sur Babel avec quelques presets se rapprochant de la syntaxe TypeScript (types, annotations, décorateurs, propriétés de classes...). C'est une sorte d'intermédiaire entre Flow et TypeScript, qui me donnait une porte de sortie (au cas où) tout en pouvant utiliser la documentation TS pour Angular.

Tu utilises donc Flow, même si tu ne l'inclus pas dans le build. Mais en quoi selon toi Flow serait-il plus rassurant que TypeScript à terme ?
Personnellement, je ne vois pas très bien pourquoi l'un serait plus pérenne que l'autre (même si j'ai plutôt l'impression que TypeScript me semble mieux partit pour), d'autant que le code JavaScript généré par TypeScript peut tout à fait être repris comme nouveau code source, même si pour le moment, je n'ai jamais observé de retour en "arrière".

Concernant les principales différences ("expérience") entre TypeScript et Flow, ce pourrait faire l'objet d'un article en soi, mais Flow n'ajoute pas de construction syntaxique qui ne préexiste pas déjà avec ES6. C'est un type checker. TypeScript lui étend la syntaxe de JavaScript au delà de ES6 en permettant par exemple l'encapsulation, les enum, les namespaces, etc. Aussi, TypeScript peut se substituer à la fois à Flow et à Babel, dans la plupart des cas. Aussi, ce qui est appréciable avec TypeScript, est l'homogénéité dans l'outillage proposé par les différents IDE et éditeurs (autocomplétion, analyse syntaxique à la volée, refactoring, etc). Dans la mesure où ces fonctionnalités sont fournies par le compilateur lui-même et non par l'IDE, cela permet de bénéficier des mêmes fonctionnalités qu'on soit sur Visual Studio, Visual Studio Code, Atom, Eclipse, Sublime, WebStorm, etc. Pour bénéficier de ces fonctionnalités avec Flow, il me semble que le choix d'IDE/éditeur est plus restreint.

Sinon, même si tu n'as pas utilisé TypeScript dans ton projet, je trouve que ça va dans le "bon" sens. J'observe autour de moi de nombreux développeurs qui s'intéressent à TypeScript et au typage en général pour des projets JavaScript ce qui est très positif. Les mentalités évoluent. Je pense que le typage finira par s'imposer dans les prochaines années parmi la communauté des développeurs Web, on en avait déjà discuté il me semble.

[SylvainPV]

Je n'ai pas plus confiance en l'avenir de Flow non plus, mais j'ai ce plugin Babel au build qui retire automatiquement les indications de type. Et les indications de type sont totalement optionnelles, elles n'influent pas sur la logique du code. Donc si un jour je dois me débarasser de Flow, je lance ce plugin et hop, j'ai du JS vanilla sans aucune retouche à faire

Pour d'autres syntaxes comme les décorateurs, là pas le choix il faudra réécrire le code si on souhaite s'en débarrasser. C'est le prix à payer pour pouvoir utiliser Angular 2 sans se lamenter devant le manque de doc sur la partie JavaScript. TS apporte de nouvelles fonctionnalités, mais c'est justement ça qui rend plus compliqué l'éventuel retour à du JS classique après coup, et c'était là mon point de vigilance qui m'a amené à faire ce choix là.

Reprendre le code source généré par TypeScript compiler n'aurait pas été envisageable puisque l'on souhaitait une codebase ES6. Aussi, même si l'output est relativement propre comparé à d'autres compilateurs, il faut pas se mentir, c'est loin d'être l'idéal non plus pour servir de nouvelle base. Une autre raison qui nous a fait écarter TypeScript est qu'il n'était pas tout à fait au point question support ES6 comparé à Babel. Certains codes passaient sous Babel mais pas sous TS. J'ignore si ça a été amélioré depuis, je vois qu'il est à 59% sur http://kangax.github.io/compat-table/es6/

[Paleo]

Le bilan est donc globalement positif, mais il y a quand même quelque-chose qui me gène: j'ai l'impression qu'en apprenant ce TypeScript-like, mes collègues en viennent à désapprendre le JS. Ils utilisent désormais presque exclusivement des classes, quitte à en déclarer beaucoup trop qui ne servent qu'une fois alors que des objets littéraux feraient parfaitement l'affaire. On a également beaucoup d'héritage avec class extends, alors que je m'étais juré de favoriser la composition et de limiter les hiérarchies d'objets. Et j'ai beau encourager un style de programmation fonctionnelle, la codebase actuelle est très orientée OOP classique avec beaucoup d'objets mutables et un usage omniprésent de this. Bref j'ai l'impression de bosser sur un projet Java / C#, et ça ne me plaît pas beaucoup. Vous connaissez le proverbe "Quand on a qu'un marteau, tout ressemble à un clou" ? Eh bien c'est à peu près ce qui se passe ici selon moi: toutes les nouveautés TS sont utilisées abusivement et le JS vanilla semble délaissé.

Aujourd'hui le "JS vanilla" inclue la POO classique à base de classes. Tes collègues n'utilisent certes pas correctement JavaScript, ils se cantonnent à un sous-ensemble du langage, les classes. Pour ma part j'interdis l'héritage à mon équipe sauf cas exceptionnel qu'il faut alors bien m'expliquer car je valide rarement.

Cela dit, yahiko a raison, tu n'as pas utilisé TypeScript. La grande force de TypeScript, ce sont les interfaces. Ces interfaces qui justement donnent du typage aux objets POJO que tu apprécies.

Je n'ai pas plus confiance en l'avenir de Flow non plus, mais j'ai ce plugin Babel au build qui retire automatiquement les indications de type. Et les indications de type sont totalement optionnelles, elles n'influent pas sur la logique du code. Donc si un jour je dois me débarasser de Flow, je lance ce plugin et hop, j'ai du JS vanilla sans aucune retouche à faire

Alors qu'avec TypeScript, tu ne dépendrais pas d'un plugin dont la maintenance est hypothétique. Il te suffirait de prendre le code compilé, ce qui restera possible tant que le langage existera. TypeScript, sur ce plan-là, est sans risque, au même titre que SCSS par rapport aux CSS par exemple. Le code généré est tellement proche de l'original que les développeurs peuvent embrayer dessus sans difficulté.

Eh oui, je fais partie de la "secte" qui pense que le typage fort dynamique est plus adapté pour JS que le typage statique, trop limité dans son champ d'action. Je voulais d'ailleurs bosser sur une vidéo explicative pour ObjectModel prochainement, ce sera peut-être l'occasion de détailler mon point de vue plus clairement.

Un Flow un peu tweaké ne vaut pas un TS-like. Flow est à JavaScript ce que Hack fut à PHP 5 : une erreur d'orientation de la part d'une boite qui a les moyens de persister dedans. Mais les interfaces de TypeScript sont concurrentes à ton bébé. Il est possible qu'il y ait là de quoi te faire passer à côté de TypeScript, sincèrement, c'est dommage.

[SylvainPV]

Ce que j'entends par "standard", c'est une techno que tout le monde ne gère pas à sa sauce, il n'y a pas 10k implémentations différentes de son moteur

C'est curieux, j'avais l'exacte définition contraire de standard. Pour moi, un standard est un ensemble de spécifications établies par un organisme dit de standardisation tel que Ecma International, mais qui ne fournit pas d'implémentation de ces spécifications de manière à préserver la concurrence. Ainsi, toute entreprise respectant ces normes peut affirmer "suivre le standard" tout en ayant des performances différentes, par exemple les périphériques USB ou les normes Wi-Fi. S'il n'y a qu'une seule implémentation et qu'elle est faite par la même équipe que celle qui définit le langage, on ne peut pas parler de standard selon moi. Un spécialiste technico-lexico peut confirmer ?

Aujourd'hui le "JS vanilla" inclue la POO classique à base de classes. Tes collègues n'utilisent certes pas correctement JavaScript, ils se cantonnent à un sous-ensemble du langage, les classes.

Oui enfin les classes ES6 sont quand même très écrémées par rapport aux les classes TS. Pour rappel, en ES6 on a pas de définition de propriétés dans les classes, ni de mots-clés public/private, ni d'annotations. Ce n'est pas tout à fait comparable.

Alors qu'avec TypeScript, tu ne dépendrais pas d'un plugin dont la maintenance est hypothétique. Il te suffirait de prendre le code compilé, ce qui restera possible tant que le langage existera. TypeScript, sur ce plan-là, est sans risque, au même titre que SCSS par rapport aux CSS par exemple. Le code généré est tellement proche de l'original que les développeurs peuvent embrayer dessus sans difficulté.

Je ne vois pas en quoi TS serait plus sûr que Flow question pérennité. Les problématiques de maintenance sont les mêmes entre Flow et TSC, les entreprises qui portent ces projets ont la même ampleur, tout comme la communauté d'utilisateurs (Flow est très populaire dans la sphère React). Quant à repartir d'une codebase à partir du résultat d'une transpilation, je pense que vous rêvez un peu. On voit régulièrement le code en sortie lors du debug sur navigateur et c'est très difficile de faire le parallèle avec le code initial. Si vous avez un exemple en tête où des gens ont réussi à faire ça sur un projet conséquent, ça m'intéresse de voir comment ils ont fait.

[ABCIWEB]

Bonjour,

Concernant TypeScript, cela me semble bien parti en effet.

Vu de l'extérieur, en tant que généraliste non spécialiste javascript, CoffeeScript par exemple m'a toujours paru beaucoup plus confidentiel, et d'un autre côté Dart a eu pas mal de critiques dès sa sortie à tel point que sans sa paternité google on peut se demander s'il aurait suscité autant d'intérêt (dont la grande part de croyance chez les débutants de considérer google comme Dieu le père).

L'adoption de TypeScript par Angular et des critiques globalement positives sans point de crispation particulier, me font dire que je pourrais adopter cette surcouche sans appréhension particulière, un peu comme j'avais adopté jquery il y a quelques années mais pour d'autres besoins.

A chaque fois que je vois Python autant devant Php, ça me conforte dans ma décision de laisser tomber définitivement Php au profit de Python.

Ce n'est que le classement GitHub. Python est plus généraliste et très utilisé en entreprise ce qui le favorise naturellement dans les dépôts GitHub. Si l'on se réfère plus particulièrement au web les résultats sont très différents. Pour dire que si Python est sans doute plus intéressant "globalement", c'est moins évident pour le web. Je me demande s'il est judicieux de vouloir comparer frontalement ces deux langages en dehors de tout contexte.

[Songbird]

Bonjour,

Vu de l'extérieur, en tant que généraliste non spécialiste javascript, CoffeeScript par exemple m'a toujours paru beaucoup plus confidentiel, et d'un autre côté Dart a eu pas mal de critiques dès sa sortie à tel point que sans sa paternité google on peut se demander s'il aurait suscité autant d'intérêt (dont la grande part de croyance chez les débutants de considérer google comme Dieu le père).

Sans trop m'avancer sur le sujet, je pense que c'est principalement dû au fait que Google soit le développeur de Dart qui a suscité pas mal de rejets. (c'est l'impression que cela me donne lorsque je vois les intervenants de certains forums/actualités)

C'est également, en premier lieu, le souhait d'intégrer une implémentation de la VM dart dans tous les navigateurs qui n'a pas beaucoup plu, même si, sur le papier, je trouve cette idée pas si mauvaise.

[kilroyFR]

Je trouve ca vraiment merité pour TypeScript car c'est un reel progres pour faire du javascript. Jamais compris comment un langage aussi degueulasse que js puisse avoir autant de succes et etre aussi laborieux a utiliser.
Une telle permissitivité dans un langage est pour moi un anti pattern absolu (le mot clé var etant le summum) car ca autorise a faire tout et n'importe quoi sans aucun controle.
Depuis que je fais du typescript je prends vraiment plaisir a coder en javascript. Merci a M$ pour ça, enfin quelque chose d'utile et vraiment productif.

[yahiko]

1. Concernant la programmation concurrente en JavaScript, à noter qu'une fonctionnalité permettant de dépasser les limitations des WebWorkers est à l'étude au sein du comité ECMAScript. Il s'agit du SharedArrayBuffer.

2. TypeScript propose le paradigme OO classique, mais ne l'impose pas comme en Java. Rien n'empêche d'écrire un programme TypeScript comme on écrit un programme JavaScript (c'est d'ailleurs la recommandation officieuse de l'équipe Microsoft qui n'encourage pas l'utilisation des classes) en mentionnant juste le typage lorsque cela est nécessaire. Il convient de rappeler que l'inférence automatique des types évite de tout typer explicitement. Si le code TypeScript côtoyé ressemble à du C#, c'est sans doute que les personnes qui ont codé viennent de cette culture, mais ce n'est pas un impératif du langage en lui-même. C'est un avantage à mon sens. Cela permet à la fois aux programmeurs venant du fonctionnel et à ceux venant de la POO d'appréhender facilement ce langage.

3. Les programmes codés dans des langages à typage statiques sont statistiquement moins sujets à bugs que ceux codés dans des langages à typages dynamiques. Voir l'étude à ce sujet menée sur la plateforme GitHub :

For those with positive coefficients we can expect that the language is associated with, ceteris paribus, a greater number of defect fixes. These languages include C, C++, JavaScript, Objective-C, Php, and Python. The languages Clojure, Haskell, Ruby, Scala, and TypeScript, all have negative coefficients implying that these languages are less likely than the average to result in defect fixing commits.

Néanmoins, ceux qui souhaitent continuer à programmer en JS sont toujours libres de le faire, mais il n'est pas exact d'affirmer que le typage statique n'apporte rien en terme de fiabilité.

[codec_abc]

1. La fonctionnalité est assez pauvre. C'est juste un partage d'un tableau de bytes avec des opérations atomiques dessus. On est loin des primitives de la programmation concurrente d'un langage haut niveau (mutex/sémaphore, queue thread-safe, etc..). En l’occurrence c'est plutôt ce que l'on retrouve quand on fait de la programmation sur GPU.

2. C# est pas mal orienté coté fonctionnel. Les classes Func<T> et Action<T> permettent de retourner ou passer en paramètres des fonctions. Linq a bien poussé C# du coté fonctionnel aussi. Certes on pas du niveau de F#/Haskell/Idris/.... mais c'est pas si mal. Après les gens qui le pratique depuis longtemps ont surement un état d'esprit très "OO" s'ils ont pas fait l'effort de se tenir à jour des évolutions du langage.

3. Même si je préfère de loin les langages typés statiquement le passage cité de l'étude est étrange. Ruby et Clojure sont typés dynamiquement et Scala est bourré de "gotcha". En plus python est très similaire à Ruby et j'ai du mal a concevoir comment l'un peut-être dans une catégorie et l'autre dans celle opposé. Pour avoir regarder le papier en diagonale la méthodologie me parait approximative. D'ailleurs la phrase qui suit ta citation est la suivante : "One should take care not to overestimate the impact of language on defects". Bref on est d'accord sur le fond mais c'est clairement pas le meilleur argument pour les langages à typage statique.

[yahiko]

1. La fonctionnalité est assez pauvre. C'est juste un partage d'un tableau de bytes avec des opérations atomiques dessus. On est loin des primitives de la programmation concurrente d'un langage haut niveau (mutex/sémaphore, queue thread-safe, etc..). En l’occurrence c'est plutôt ce que l'on retrouve quand on fait de la programmation sur GPU.

3. Même si je préfère de loin les langages typés statiquement le passage cité de l'étude est étrange. Ruby et Clojure sont typés dynamiquement et Scala est bourré de "gotcha". En plus python est très similaire à Ruby et j'ai du mal a concevoir comment l'un peut-être dans une catégorie et l'autre dans celle opposé. Pour avoir regarder le papier en diagonale la méthodologie me parait approximative. D'ailleurs la phrase qui suit ta citation est la suivante : "One should take care not to overestimate the impact of language on defects". Bref on est d'accord sur le fond mais c'est clairement pas le meilleur argument pour les langages à typage statique.

1. Avec les WebWorkers qui permettent le parallélisme, l'introduction du SharedArrayBuffer est une étape supplémentaire vers la concurrence. Ton affirmation

Js n'aura probablement jamais de programmatation concurrente car ce n'est utile que pour les langages qui peuvent offrir des performances correctes ce qui n'est pas son cas.

est à mon sens excessive puisqu'à partir du moment où JavaScript dispose d'un mécanisme de mémoire partagée entre threads, il est possible de développer des bibliothèques avec les primitives que tu cites. L'obstacle ne me paraît pas du tout insurmontable. D'ailleurs, dès que les SharedArrayBuffer seront supportés par les navigateurs, il sera tout à fait possible de faire de la programmation concurrente en compilant du code concurrent C++ en WebAssembly (ou asm.js).

3. La citation choisie avait surtout pour intérêt de faire apparaître TypeScript. Pour le reste, il suffit de lire l'abstract et la conclusion pour voir que les langages à typage statique sont dans cette étude plus fiables que ceux à typage dynamique. Après, il est toujours possible de critiquer une étude, mais il me semble que c'est celle qui est la plus aboutie à ce jour sur le sujet. Après, il est un peu curieux de qualifier la méthodologie d'approximative quand on a soit même fait une lecture "approximative" (en "diagonale" si je reprends tes mots). N'hésite pas à exposer plus en détail tes reproches néanmoins. Il n'en reste pas moins qu'il s'agit d'une étude sérieuse, scientifique, même si probablement perfectible, comme tout, et que je ne connais pas de meilleur argument sur un tel sujet que la démarche scientifique.

[ludojojo]

Jamais compris comment un langage aussi degueulasse que js puisse avoir autant de succes et etre aussi laborieux a utiliser.
Une telle permissitivité dans un langage est pour moi un anti pattern absolu (le mot clé var etant le summum) car ca autorise a faire tout et n'importe quoi sans aucun controle.
Depuis que je fais du typescript je prends vraiment plaisir a coder en javascript. Merci a M$ pour ça, enfin quelque chose d'utile et vraiment productif.

Quand je lis un commentaire de ce type, je me dit que la population des développeurs à bien changé, et que c'est dommage.
Si tu ne comprends pas un langage, la puissance des prototypes, la puissance du non "typage fort" (car oui c'est quand même typé !) c'est simplement par ce que tu n'as pas de recule et que tu ne maitrise pas non plus les mécanismes interne de la POO !
La souplesse de JavaScript est l"une de ses forces.
TypeScript te permet seulement avec sa propre écriture, de générer le code JS que tu n'es pas capable de faire correctement.

Depuis que je fais du typescript je prends vraiment plaisir a coder en javascript

C'est improbable de dire ça, du TypeScript n'est pas du JavaScript. C'est un langage qui à été introduit par Microsoft dans le but d'offrir aux développeur de son écosystème VB.Net de se reconvertir tant ce dernier est en perte de vitesse. C'est pour cela que le style d'écriture en est si proche.

[SylvainPV]

@ludojojo: +1, sans oublier que JavaScript a déjà ses propres armes pour ajouter du typage fort sans recourir à un autre langage. C'est l'objet d'un article que j'ai écrit hier soir (en anglais): https://medium.com/@SylvainPV/type-s...s-eee8fbbbd600