Discussion :

[SylvainPV]

En fait on a pas mis Flow dans le build, mais on a configuré notre IDE (license Webstorm pour toute l'équipe) pour valider à la volée dans l'éditeur et bénéficier de l'autocomplétion. Le build Babel sert uniquement à retirer ces types avant la conversion ES5. Du coup je ne sais pas si ça a vraiment changé tant que ça l'expérience de développement. Il faut dire qu'on a très rarement eu des erreurs de typage à partir du moment où a des conventions de nommage très strictes et des classes pour décrire tout ce qu'on manipule. Si ça ne tenait qu'à moi, j'aurais préféré intégrer ObjectModel notamment pour valider les JSON de nos web services. C'est là qu'on a eu le plus de soucis jusqu'ici. Après on peut toujours mettrer Flow dans le build sans pour autant typer explicitement partout (l'inférence de type de Flow est déjà excellente en soi).

C'est vrai qu'on a pas besoin de TS pour faire de la POO classique en JS. Peut-être qu'on aurait eu le même résultat si on était parti sur du ES6 vanilla, va savoir. Sur ce point j'ai l'impression que c'est davantage Angular qui nous a influencé.

[yahiko]

Si vous n'utilisiez ni Flow, ni TypeScript, comment pouvez-vous détecter vos éventuels bugs sur le typage ? C'est juste une question parce que sans compilateur ni type checker, j'ai un peu de mal à voir comment on peut conclure que les annotations de typage ne corrigent aucun ou très peu de bugs. Si vous ne vous basez que sur le support WebStorm de Flow, je trouve que c'est un peu léger comme validation. Mais je peux me tromper.

[SylvainPV]

Non tu as mal compris, on utilise bien Flow mais par le biais de file watchers configurés dans Webstorm. Même chose pour les linters JSCS et Stylelint. Toutes les validations ont lieu au sein de l'éditeur, directement quand on modifie le code source. C'est une fonction directement intégrée sur certains éditeurs gratuits comme Nuclide. Pour avoir essayé rapidement TypeScript sur Webstorm, je n'ai pas eu l'impression que l'expérience soit sensiblement différente.

Et on a bien Babel comme compilateur pour supprimer les éléments non-standards et transpiler en ES5, mais on a essayé de réduire au maximum la phase de build pour avoir une expérience de dev fluide.

[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/

[yahiko]

Entre nous, et on ne va pas se mentir aussi, je ne vois pas de raison pourquoi vous retourneriez au JS Vanilla. Je n'ai jamais observé de retour en arrière dans les projets TS (pour Flow je ne sais pas mais on va dire que c'est pareil). Tes craintes à mon avis sont mal placées.
Sur la transpilation ES6 vers ES5, TS a bien progressé depuis, surtout qu'au pire il est possible de chaîner Babel si vraiment on tient à certaines syntaxes ES6 qui ne sont pas encore supportées par TS.

[SylvainPV]

On a pas vécu les mêmes expériences, simplement J'ai fait l'expérience de faire la maintenance d'un vieux projet CoffeeScript et c'était mission impossible pour avoir du support, plein de dépendances n'étaient plus maintenues. Il est en train d'arriver la même chose à un collègue qui a repris un prototype écrit en Dart et où ils ont décidé de faire un rewrite complet en JS. J'ai vu trop souvent des conférences où on annonce le super langage qui va remplacer JS, où les gens excités démarrent leurs projets avec et deux ans plus tard ils regrettent leur décision.

Peut-être que je me trompe pour TS, il a l'air mieux parti que les autres, mais on disait la même chose à l'époque pour CoffeeScript. Je ne sais pas si tu as connu la "grande époque CoffeeScript" dans ton milieu professionnel. A l'époque j'ai connu une personne qui faisait preuve de beaucoup d'engouement pour CS, le même engouement dont tu fais preuve pour TS aujourd'hui de par tes nombreuses publications sur le sujet. Et il avait des arguments très convaincants, je me rappelle d'une présentation qui avait conquis tout le monde en voyant tous les avantages. Seulement voilà, aujourd'hui il code son front en JS.

[yahiko]

Même si je n'ai jamais été pas un fervent admirateur de CoffeeScript, et c'est un euphémisme, il me semble que ce langage continue d'évoluer et reste populaire auprès d'une part non négligeable de la communauté des développeurs Web. Le manque de support que tu évoques me laisse donc perplexe. Et tu pouvais repartir sur le résultat JS qui bien qu'étant légèrement moins "propre" que le code produit par TypeScript reste à mon sens exploitable par un humain. Après, les dépendances non maintenues, ça existe aussi en JavaScript (et dans d'autres langages mainstream comme Java ou C++). D'ailleurs c'est souvent des modules internes, home made, qui sont les premiers touchés par ce syndrome. C'est donc souvent moins affaire de langage que de développeurs (et de documentation suffisante...).

Je connais bien cet argument du "et si tel langage disparaît". Il existe depuis l'invention de l'informatique ^_^
Tout d'abord un langage ne disparaît jamais. Il faudrait d'ailleurs réfuter systématiquement cette assertion.
Ensuite, en général, ce qui freine les migrations et les évolutions d'une base de code, ce n'est pas parce qu'un langage est resté figé à une norme X depuis Y années, mais avant tout parce que la qualité logicielle au sens large de cette base de code est insuffisante pour évoluer.

Enfin, je conclurai sur ta remarque son mon "enthousiasme" pour TypeScript. Je fais moins la promotion de TypeScript en tant que tel que la promotion d'une évolution des mentalités chez les développeurs JavaScript qui rejettent à tort (à mon sens) l'idée du typage et des constructions syntaxiques qui ne sont pas propre à JS. C'est surtout en réaction à un certain sectarisme dans le milieu que je me plait à titiller ce petit monde. Ca ne plaît pas à tout le monde, je peux le constater autour de moi. Mais je pense que c'est salutaire

[Songbird]

Salut,

Enfin, je conclurai sur ta remarque son mon "enthousiasme" pour TypeScript. Je fais moins la promotion de TypeScript en tant que tel que la promotion d'une évolution des mentalités chez les développeurs JavaScript qui rejettent à tort (à mon sens) l'idée du typage et des constructions syntaxiques qui ne sont pas propre à JS. C'est surtout en réaction à un certain sectarisme dans le milieu que je me plait à titiller ce petit monde. Ca ne plaît pas à tout le monde, je peux le constater autour de moi. Mais je pense que c'est salutaire

Je suis plutôt d'accord avec cette partie de ton message. Moi ça ne me dérangerait absolument pas que JS soit totalement standardisé comme peuvent l'être ses surcouches, qu'il bénéficie d'un typage statique (mais optionnel pour ceux qui ne veulent pas l'utiliser), d'un type checker, etc. Je ne vois pas vraiment où est le mal de faire évoluer une techno qui s’essouffle dans sa forme actuelle.

[SylvainPV]

@Songbird: Qu'est-ce que tu veux dire par "ça ne me dérangerait absolument pas que JS soit totalement standardisé comme peuvent l'être ses surcouches" ? Je ne sais pas trop quelle définition tu as de "standard", mais dans mon esprit c'était plutôt JavaScript qui suivait le standard ECMAScript tandis que les surcouches étaient libres d'évoluer n'importe comment, puisque l'éditeur fournit à la fois le langage et l'implémentation.

Concernant la techno qui s'essoufle en parlant de JavaScript, c'est clair que je ne partage pas du tout la même vision que toi en voyant le graphe publié par yahiko Depuis ES6 le JS est métamorphosé, et on a maintenant des mises à jour annuelles de la norme ECMAScript. D'après moi le langage a dormi pendant 15 ans, a été un peu remué par la révolution mobile, et s'est complètement reveillé ces dernières années. Aujourd'hui il n'a jamais été aussi populaire et actif, ce qui n'est pas pour me déplaire.

@yahiko: Certes, les langages ne disparaissent pas, ce sont les développeurs qui les pratiquent qui disparaissent. C'est ce qui est arrivé avec CoffeeScript: des libs open source abandonnées par leur auteur et pas de gens compétents disponibles en interne pour les reprendre. L'adoption de masse est essentielle en entreprise, on ne peut pas simplement choisir un langage parce qu'il est meilleur, sinon je ferais du Elm
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.

[Songbird]

Qu'est-ce que tu veux dire par "ça ne me dérangerait absolument pas que JS soit totalement standardisé comme peuvent l'être ses surcouches" ? Je ne sais pas trop quelle définition tu as de "standard"

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, ... Un langage qui possède un véritable standard, quoi. (mais oui effectivement ES6 est arrivé et a sauvé un peu la mise, toujours est-il qu'il n'existe toujours pas de véritable système d'import (sauf erreur de ma part))

mais dans mon esprit c'était plutôt JavaScript qui suivait le standard ECMAScript tandis que les surcouches étaient libres d'évoluer n'importe comment, puisque l'éditeur fournit à la fois le langage et l'implémentation.

Bah justement, jusqu'ici les surcouches imposent directement les fonctionnalités de l'ES6 (qui, rappelons-le, ne sont que de simples formalités dans la plupart des langages) et plus si affinité, mais on avait au moins les features de la dernière version du standard. JavaScript suit ce standard, certes, mais nombre de ressources (et de sites) utilisent encore des fonctionnalités obsolètes, ce qui me pousse à dire que l'ES6 sera respecté quand une nouvelle version du standard sortira, ce qui n'aide vraiment pas.

Concernant la techno qui s'essoufle en parlant de JavaScript, c'est clair que je ne partage pas du tout la même vision que toi en voyant le graphe publié par yahiko Depuis ES6 le JS est métamorphosé, et on a maintenant des mises à jour annuelles de la norme ECMAScript. D'après moi le langage a dormi pendant 15 ans, a été un peu remué par la révolution mobile, et s'est complètement reveillé ces dernières années. Aujourd'hui il n'a jamais été aussi populaire et actif, ce qui n'est pas pour me déplaire.

(Je ne vise pas JS, donc ne me jetons pas des cailloux )

Popularité n'est pas forcément un signe de qualité, attention à ne pas confondre.
JavaScript est populaire car connu et enseigné partout, ça ne veut pas dire qu'il est d'une certaine qualité pour autant.

En revanche lorsque je parle du fait de "s'essouffler", je ne parle pas vraiment du désamour des développeurs à son égard, mais bien du fait que JavaScript est obligé de ramer comme un damné pour évoluer et obtenir des fonctionnalités que des surcouches de ce dernier disposent déjà nativement et pour une grande majorité d'entre-elles.

[TiranusKBX]

@Songbird_ le import est prévus mais pour le moment aucun navigateur ne l'a implémenté vus la complexité que ça demande

[Songbird]

@Songbird_ le import est prévus mais pour le moment aucun navigateur ne l'a implémenté vus la complexité que ça demande

Tu aurais un lien ?

[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.

[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.

[Paleo]

JSweet est fait pour tes collègues
http://www.jsweet.org/
A+JYT

La première ligne du premier exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

package animation;

… traduite en JS par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
var animation;
(function (animation) {
  // …
})(animation || (animation = {}));

… et en TS par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
module animation {
	// …
}

C'est obsolète.
Je déconseille.
Il existe des concepts en TypeScript/JavaScript qui n'ont pas d'équivalents en Java ou bien dont l'application est plus large.

Les modules ES6 en sont un. Ils remplacent en mieux les packages Java, ils ne sont pas un concept équivalent. Le concept JS équivalent est effectivement une variable globale, comme dans l'exemple, c'est-à-dire la plupart du temps une mauvaise pratique.

Et aussi, en TS, ce mot-clé "module" est devenu "namespace".

[sekaijin]

le propos n'est pas d'apporter dans java les capacité des langages TS ou JS mais de permettre à des développeurs java de travailler en java pour produire des application côté client (en ts ou js). les développeurs java veulent continuer à utiliser les concepts java.

quant à la traduction elle dépends du niveau EcmaScript demandé à la compilation.

il ne s'agit pas non plus comme d'autre solution de faire fonctionner une JVM dans le navigateur.

il s'agit donc simplement d'utiliser les outils java avec les concepts java pour produire des applications JS.
je réponds donc à la personne qui dit que ces développeurs java on envie de rester dans leur univers que jsweet est une solution pour eux.

lorsque tu programme en C++ tu ne regarde pas de près quels sont les compromis que fait ton compilateur et si le binaire produit n'est pas des plus orthodoxe par rapports au toutes dernières méthodes ce qui t'intéresse c'est que ça fonctionne, que ça n'occupe pas trops de ressources, que ça a les perf attendue et que ça ne plante pas.
ton compilateur peut produire un binaire complètement contraire aux bonnes pratiques des développeurs en assembleur, tu n'en a rien à faire.


Quant à ouvrir un exemple ES5 et dire je déconseille d'utiliser cette techno parce que en ES6 blabla... c'est un peut court.
A+JYT

[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.

[Paleo]

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.

Oui, c'est vrai, mais l'usage est proche. Et les classes TS sont d'ailleurs compilées en classes JS.

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.

Parce que le code est compilé pour EcmaScript 3 ou 5. Essayez de le compiler pour ES6 (option de compilation "--target"). Vous obtiendrez ce que vous cherchez.