Discussion :

[Engiwip]

Bonjour .
Avec babel , les spec ES7 et flow pour javascript nous pouvons profiter encore de l écosystème javascript côté client comme cote serveur avec un typage fort et une structure js plutôt agréable

Alors Typescript pour quelle utilité ?

[Marco46]

Pour avoir tout en un.

Je ne connais pas les différences exactes entre flow et TypeScript mais il doit y en avoir.

Vue3 a fait le choix de TypeScript aussi. On voit aussi de plus en plus de projets React avec du TypeScript. Et Ryan Dahl réécrit son reboot de node avec TypeScript actif out of the box.

C'est clairement un choix très solide.

EDIT : Le vrai danger avec TypeScript c'est de le confondre à la va-vite avec un langage de la catégorie Java / C#. Ca n'a absolument aucun rapport. C'est juste un superset de JS, pas du tout un langage à part entière.

Du coup il faut vraiment éviter de chercher absolument à imiter un design de type POO comme avec Java / C#. C'est à mon sens la plus grosse erreur de Angular dont le mécanisme d'injection de dépendances est le plus gros avatar.

Comme l'a dit le lead dev de TypeScript dans un de ses tweets :

"I'm using TypeScript so I have to write OOP code with classes" :: "I got a paintbrush from Home Depot so I have to paint my house orange"

[Engiwip]

Salut.
Je vois bien les avantages de la OOP. Mais n est ce pas inutile au final ?
Avec l orientation que prennent l ecritures des services comme des fonctions ,la fin de l héritage préfèré a la composition.
L aspect modulaire et asynchrone de node . Je n ai pas trouvé l utilité des patterns oop de typescript.
Au final Ca rajoute une couche de transpilation donc de complexite en plus.

Puis quand on voit des api entieres codées en golang on doit pour voir se passer des generics et autre prototype en node cote serveur et javascript cote client.
...

En fait je ne suis pas convaincu que Typescript s inscrive dans la durée pour que ca devienne un choix incontournable .


De nouveau acteurs comme rust- nucleon ou kotlin sur javascript permettent la même promesse que Typescript avec la possibilité d apprendre kotlin pour d autre utilité comme le mobile.

[Marco46]

Je n ai pas trouvé l utilité des patterns oop de typescript.

Mais justement, c'est ce que j'ai écrit dans mon message précédent, il n'y a aucune obligation à faire de la POO avec TypeScript. Aucune.

Il n'y a pas de pattern OOP dans TypeScript. C'est un système de typage statique structurel qui n'a aucun impact au runtime (sauf si tu écris des types guards ce qui peut se révéler très utile).

Au final Ca rajoute une couche de transpilation donc de complexite en plus.

Babel aussi. La phase de transpilation permet de cibler le plus bas dénominateur commun que tu devras supporter en terme de version du JavaScript OK sur tes moteurs d'exécutions cibles.

En gros si t'as IE11 dans la liste tu cibles E5. Sinon tu remontes au fur et à mesure, cf les Kangax tables.

La transpilation ne sert pas seulement à ajouter un système de typage, ça permet de faire le même boulot que Babel avec en plus le système de typage.

TypeScript c'est JavaScript normal + un système de type à la phase de transpilation.

Puis quand on voit des api entieres codées en golang on doit pour voir se passer des generics et autre prototype en node cote serveur et javascript cote client.

Je ne comprends pas trop le rapport avec Golang. Le fait de typer permet d'avoir des contrats clairs quand tu découples les différentes parties de ton appli.

Au cours des derniers mois j'ai migré 2 applis en JavaScript vers TypeScript, d'abord une appli front de ES5 avec des IIFE vers TypeScript (grosse galère) et ensuite une appli back (type outil CLI, pas API) de ESNext à TypeScript et j'en suis très content.

J'étais vraiment très sceptique sur TS et au final je trouve que ça clarifie considérablement les choses, il faut par contre se taper une phase d'apprentissage assez longue parce que ce n'est pas ce qu'on pense de prime abord. Ce n'est pas du Java ou du C# adapté à JS. Rien à voir.

Ça a aussi l'avantage d'être, je trouve, beaucoup plus simple à utiliser que Babel et ses multiples modules.

Après est-ce que c'est obligatoire ? Je ne pense pas. Mais c'est un vrai confort, en particulier pour définir tes modèles de données et jouer avec.

En fait je ne suis pas convaincu que Typescript s inscrive dans la durée pour que ca devienne un choix incontournable .

Les exemples que je t'ai cité (Vue3, deno, ...) semblent montrer que si.

Mais on y est pas encore. Quand deno commencera à remplacer node là je pense que ça va vraiment accélérer les choses. Mais c'est à un horizon 5 ans minimum. Ce reboot de node résout des problèmes insolvables dans l'architecture actuelle qui sont fondamentaux, et à terme ça va favoriser deno au profit de node. Évidemment c'est de la prédiction à 2 balles sur un forum mais je le sens bien

De nouveau acteurs comme rust- nucleon ou kotlin sur javascript permettent la même promesse que Typescript avec la possibilité d apprendre kotlin pour d autre utilité comme le mobile.

Ce n'est pas comparable avec TypeScript.

Il s'agit ici de prendre un langage A et de le transpiler en un langage B.

TypeScript c'est un langage A + des extensions qui transpile en un langage A sans les extensions.

C'est très différent comme concept. Tout code JS est un code TS compatible.

[Paleo]

Bonjour .
Avec babel , les spec ES7 et flow pour javascript nous pouvons profiter encore de l écosystème javascript côté client comme cote serveur avec un typage fort et une structure js plutôt agréable

Alors Typescript pour quelle utilité ?

Bonjour, la question est à l'envers. On n'a pas besoin de justifier pourquoi choisir le leader plutôt que le challenger. En revanche on pourrait se demander :

- Pourquoi Hack plutôt que PHP ?
- Pourquoi Yarn plutôt que Npm ?
- Pourquoi Cassandra plutôt que HBase ?
- Pourquoi Flow plutôt que TypeScript ?

J'ai pour ma part un doute sur la pérennité de Flow, car sa base d'utilisateurs me semble très attachée à la galaxie React. Or, React est un framework frontend, et les leaders des frameworks frontends ne le restent que quelques années.

À part ça, il n'y a pas de rapport entre TypeScript et l'OOP. Il y en avait un il y a six ans, lorsque 6to5 (devenu Babel) n'existait pas et que la seule manière d'avoir des classes dans la future syntaxe de JavaScript était TypeScript. Ce sont de bons souvenirs, mais nous ne sommes plus en 2013.

Dernière remarque : ES2016 (ES7) a trois ans. C'était avant async / await. Nous en sommes à ES2018.

[Engiwip]

j'aime bien tes remarques
je reponds à maniere sans conflit , pour j'espere faire avancer le bouzin.

Mais justement, c'est ce que j'ai écrit dans mon message précédent, il n'y a aucune obligation à faire de la POO avec TypeScript. Aucune.

La transpilation ne sert pas seulement à ajouter un système de typage, ça permet de faire le même boulot que Babel avec en plus le système de typage.

TypeScript c'est JavaScript normal + un système de type à la phase de transpilation.

ok donc je ne vois pas d'utilité à prendre TypeScript

Je ne comprends pas trop le rapport avec Golang. Le fait de typer permet d'avoir des contrats clairs quand tu découples les différentes parties de ton appli.

oui tu as raison je me suis mal exprimé . Je voulais dire que l'exemple de l'utilisation d'un langage comme golang revient vers plus de simplicité. donc avec les fonctionnalités de javascript çà devrait suffire pour mener à bien un projet nodejs. sans superset.

Au cours des derniers mois j'ai migré 2 applis en JavaScript vers TypeScript, d'abord une appli front de ES5 avec des IIFE vers TypeScript (grosse galère) et ensuite une appli back (type outil CLI, pas API) de ESNext à TypeScript et j'en suis très content.

J'étais vraiment très sceptique sur TS et au final je trouve que ça clarifie considérablement les choses, il faut par contre se taper une phase d'apprentissage assez longue parce que ce n'est pas ce qu'on pense de prime abord. Ce n'est pas du Java ou du C# adapté à JS. Rien à voir.

ok mais s'il a fallu une phase d'apprentissage assez longue . je n'en vois l'utilité au final.
enfin çà t' a permis de t'eclater dans ton dev c'est déjà çà.

Ça a aussi l'avantage d'être, je trouve, beaucoup plus simple à utiliser que Babel et ses multiples modules.

désolé je ne vois pas le rapport au niveau de la simplicité , Babel c'est une déclaration dans le fichier json tout en profitant de l'ecosystem des packages npm par la suite

Après est-ce que c'est obligatoire ? Je ne pense pas. Mais c'est un vrai confort, en particulier pour définir tes modèles de données et jouer avec.



Les exemples que je t'ai cité (Vue3, deno, ...) semblent montrer que si.

Mais on y est pas encore. Quand deno commencera à remplacer node là je pense que ça va vraiment accélérer les choses. Mais c'est à un horizon 5 ans minimum. Ce reboot de node résout des problèmes insolvables dans l'architecture actuelle qui sont fondamentaux, et à terme ça va favoriser deno au profit de node. Évidemment c'est de la prédiction à 2 balles sur un forum mais je le sens bien



Ce n'est pas comparable avec TypeScript.

Il s'agit ici de prendre un langage A et de le transpiler en un langage B.

TypeScript c'est un langage A + des extensions qui transpile en un langage A sans les extensions.

C'est très différent comme concept. Tout code JS est un code TS compatible.

Ok çà a le merite d'etre clair

[Engiwip]

Bonjour ,
je tente une réponse.

Bonjour, la question est à l'envers. On n'a pas besoin de justifier pourquoi choisir le leader plutôt que le challenger.

la question est tout à fait à l'endroit , tu viens d'y repondre toi meme.
pourquoi choisir le challenger quand on a le leader. et que l'existence du challenger dépend uniquement de la presence et pertinence du leader

J'ai pour ma part un doute sur la pérennité de Flow, car sa base d'utilisateurs me semble très attachée à la galaxie React. Or, React est un framework frontend, et les leaders des frameworks frontends ne le restent que quelques années.

je ne comprends pas cette logique d'opposer front end au backend avec javascript.
on utilise bien javascript avec nodejs coté server . donc tout ce qui est permis au front est permis au back ( en lib javascript j'entend)
sinon qu'elle utilité de prendre un backend en javascript si ce n'est pour beneficier de l"ecosysteme global ?

on n'est pas obligé d'utiliser les conventions commonjs coté node mais on peut prendre les dernieres spec ES2018 et faire de beaux import avec des accolades
enfin bref tout çà pour dire que Flow coté serveur prend tout son sens .

À part ça, il n'y a pas de rapport entre TypeScript et l'OOP.

bah un peu quand meme ,constructor , class , interface , generic c'est un peu de l'OOP non ?

Dernière remarque : ES2016 (ES7) a trois ans. C'était avant async / await. Nous en sommes à ES2018.

c'est exact Async await c est es2017 mais c est pas grave. Hein on ne va pas me faire un proces pour ne pas connaître par coeur la nomenclature de ecsmascript
Du coup quelle avancée tu retiens de ES2018?

[Paleo]

En fait je ne suis pas convaincu que Typescript s inscrive dans la durée pour que ca devienne un choix incontournable.

Ce sont deux points distincts.

1. TypeScript va durer. Il est devenu LE moyen de documenter une API. La base des définitions accessible par "@types/" est gigantesque et aujourd'hui de nombreux programmeurs JavaScript se préoccupent eux-même de publier les typages directement dans leurs packages. Il n'y a pas du tout l'équivalent sur Flow.

En outre, TypeScript est un pilier de la nouvelle stratégie ouverte de Microsoft. L'IDE VS Code est codé en TypeScript, et avec le tout nouveau Azure Data Studio qui en reprend l'apparence, je me demande si VS Code ne deviendrait pas un framework multi-OS modulable. Toujours sur le fait que Microsoft prenne la technologie au sérieux : JavaScript est aussi devenu un citoyen de première classe sur Windows, et Anders Hejlsberg (Turbo Pascal, Delphi, DotNet) contribue activement à TypeScript.

2. TypeScript restera toujours un choix optionnel par rapport à JavaScript. Donc pas un choix incontournable. À part peut-être sur l'aspect documentation.

pourquoi choisir le challenger quand on a le leader. et que l'existence du challenger dépend uniquement de la presence et pertinence du leader

TypeScript est en concurrence avec Flow, pas avec JavaScript. TypeScript est JavaScript, plus du typage. Tout comme Flow.

enfin bref tout çà pour dire que Flow coté serveur prend tout son sens.

Je n'ai pas dit le contraire. La pérennité d'une technologie dépend beaucoup du nombre d'utilisateurs. Si l'on retire les développeurs React, il ne reste plus beaucoup d'utilisateurs de Flow. Et React ne restera pas éternellement leader sur son créneau. Ce qui pose la question : Flow est-il inscrit dans la durée ?

bah un peu quand meme ,constructor , class , interface , generic c'est un peu de l'OOP non ?

JavaScript intègre les outils pour l'OOP : les classes et les constructeurs font partie de JavaScript depuis 4 ans (ES2015).

Les interfaces et les types génériques de TypeScript ne sont pas caractéristiques de la programmation orientée objets.

[Marco46]

ok donc je ne vois pas d'utilité à prendre TypeScript

Alors tu ne vois pas non plus celle de flow ?

oui tu as raison je me suis mal exprimé . Je voulais dire que l'exemple de l'utilisation d'un langage comme golang revient vers plus de simplicité. donc avec les fonctionnalités de javascript çà devrait suffire pour mener à bien un projet nodejs. sans superset.

Oui tu peux.

ok mais s'il a fallu une phase d'apprentissage assez longue . je n'en vois l'utilité au final.
enfin çà t' a permis de t'eclater dans ton dev c'est déjà çà.

Le code est je trouve beaucoup plus clair ça te force à avoir un certain niveau de qualité.

Je ne pense pas que ça réduise les bugs, dans le sens où c'est la manière d'automatiser les tests qui est la plus importante à ce niveau mais ça améliore grandement la lisibilité. Et comme tous les outils il y a une phase d'apprentissage c'est normal. Ca sera pareil avec flow ou n'importe quoi d'autre.

désolé je ne vois pas le rapport au niveau de la simplicité , Babel c'est une déclaration dans le fichier json tout en profitant de l'ecosystem des packages npm par la suite

Il faut importer le package principal mais aussi tout ce que tu veux utiliser comme plugin et aussi flow du coup. Avec TypeScript tu importes TypeScript, point final.

Côté linter tu remplaces ESLint avec TSLint qui est vraiment très bien.

[Marco46]

la question est tout à fait à l'endroit , tu viens d'y repondre toi meme.
pourquoi choisir le challenger quand on a le leader. et que l'existence du challenger dépend uniquement de la presence et pertinence du leader

Sauf que tu inverses les termes. Le leader c'est très clairement TypeScript.

bah un peu quand meme ,constructor , class , interface , generic c'est un peu de l'OOP non ?

Tu peux parfaitement développer dans un style fonctionnel avec tout ça. C'est même très agréable d'avoir du typage sur des fonctions pures.

[Engiwip]

Ce sont deux points distincts.

1. TypeScript va durer. Il est devenu LE moyen de documenter une API. La base des définitions accessible par "@types/" est gigantesque et aujourd'hui de nombreux programmeurs JavaScript se préoccupent eux-même de publier les typages directement dans leurs packages. Il n'y a pas du tout l'équivalent sur Flow.

En outre, TypeScript est un pilier de la nouvelle stratégie ouverte de Microsoft. L'IDE VS Code est codé en TypeScript, et avec le tout nouveau Azure Data Studio qui en reprend l'apparence, je me demande si VS Code ne deviendrait pas un framework multi-OS modulable. Toujours sur le fait que Microsoft prenne la technologie au sérieux : JavaScript est aussi devenu un citoyen de première classe sur Windows, et Anders Hejlsberg (Turbo Pascal, Delphi, DotNet) contribue activement à TypeScript.

2. TypeScript restera toujours un choix optionnel par rapport à JavaScript. Donc pas un choix incontournable. À part peut-être sur l'aspect documentation.


TypeScript est en concurrence avec Flow, pas avec JavaScript. TypeScript est JavaScript, plus du typage. Tout comme Flow.

.

ok Tout ceci m'eclaire profondement .merci.

Je n'ai pas dit pas le contraire. La pérennité d'une technologie dépend beaucoup du nombre d'utilisareurs. Si l'on retire les développeurs React, il ne reste plus beaucoup d'utilisateurs de Flow. Et React ne restera pas éternellement leader sur son créneau. Ce qui pose la question : Flow est-il inscrit dans la durée ?

bonne question.
du coup j'en ai une autre : est ce que les dev du projet nodejs ambitionnent de tout réecrire en typescript ?

Les interfaces et les types génériques de TypeScript ne sont pas caractéristiques de la programmation orientée objets.

?
a partir du moment ou ceci aide a modeliser , definir un comportement ou un contrat, etc les interfaces et generics font partie de la POO.
mais là ce n'est plus le sujet

[Engiwip]

Le code est je trouve beaucoup plus clair ça te force à avoir un certain niveau de qualité.

Je ne pense pas que ça réduise les bugs, dans le sens où c'est la manière d'automatiser les tests qui est la plus importante à ce niveau mais ça améliore grandement la lisibilité. Et comme tous les outils il y a une phase d'apprentissage c'est normal. Ca sera pareil avec flow ou n'importe quoi d'autre.

Il faut importer le package principal mais aussi tout ce que tu veux utiliser comme plugin et aussi flow du coup. Avec TypeScript tu importes TypeScript, point final.

Côté linter tu remplaces ESLint avec TSLint qui est vraiment très bien.

ok c'est pertinent . je ne suis pas borné hein ? mais j'hesite avant de plonger.

[Paleo]

est ce que les dev du projet nodejs ambitionnent de tout réecrire en typescript ?

Pas à ma connaissance. Le projet de refaire Node.js avec typeScript, c'est Deno, déjà signalé plus haut par l'ami Marco46. Il faudra attendre quelques années pour voir ce que ça donne.

?
a partir du moment ou ceci aide a modeliser , definir un comportement ou un contrat, etc les interfaces et generics font partie de la POO.
mais là ce n'est plus le sujet

La POO implique des hiérarchies de classes. Les interfaces ou les types génériques sont des outils de documentation du code. Par exemple où serait la POO selon toi dans ce code :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
interface FormatTextOptions {
  startSentenceWithCapitalLetter?: boolean
  fixSpaces?: boolean
  fixQuotes?: boolean
}
 
function formatText(text: string, options: FormatTextOptions = {}) {
  // ...
  return text;
}

[Engiwip]

Bah sous tes yeux.
Tu as un objet compose par les éléments de l interface.
On revoit les design pattern ?

[Marco46]

Pour être complet il faut citer l'article de Eric Elliott, The TypeScript Tax qui est devenu un classique sur ce sujet (14K claps sur medium c'est vraiment énorme).

Il va plutôt dans le sens de ne pas utiliser TypeScript sur de grosses applis en production.

Je l'avais lu en janvier et je viens de voir qu'il a mis à jour certaines choses. Les commentaires sont aussi intéressants à lire.

[Paleo]

L'avis d'Eric Elliott est valable dans le contexte de la programmation fonctionnelle, car il est en effet difficile de typer des fonctions d'ordre supérieur (des fonctions qui retournent des fonctions). La version 3.4 de TypeScript, sortie cette semaine, améliore les choses.

Bah sous tes yeux.
Tu as un objet compose par les éléments de l interface.
On revoit les design pattern ?

Tu devrais surtout revoir les définitions. Pas de classes ou d'héritage, pas de POO. En JavaScript on peut manipuler des objets sans faire de POO.

[Engiwip]

Tu devrais surtout revoir les définitions. Pas de classes ou d'héritage, pas de POO. .

Okay ....bon je te souhaites un bon we merci pour ce moment.

[Engiwip]

Pour être complet il faut citer l'article de Eric Elliott, The TypeScript Tax qui est devenu un classique sur ce sujet (14K claps sur medium c'est vraiment énorme).

Il va plutôt dans le sens de ne pas utiliser TypeScript sur de grosses applis en production.

Je l'avais lu en janvier et je viens de voir qu'il a mis à jour certaines choses. Les commentaires sont aussi intéressants à lire.

mince marco tu m'avais presque convaincu ...
retour à la case départ alors ?

[Marco46]

L'avis d'Eric Elliott est valable dans le contexte de la programmation fonctionnelle, car il est en effet difficile de typer des fonctions d'ordre supérieur (des fonctions qui retournent des fonctions). La version 3.4 de TypeScript, sortie cette semaine, améliore les choses.

J'ai pas encore regardé TS3.4 mais perso je fais ce genre de choses :

Code typescript :

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

1
2
3
 
declare type MapParsedDocumentFnType = (mdParsedDocument: IMdParsedDocument) => ITargetDocument;
declare type UnConfiguredMapParsedDocumentFnType = (conf: { markedOptions: MarkedOptions }) => MapParsedDocumentFnType;

Après je fais encore beaucoup de conneries avec ce paradigme, pas assez d'expérience et très difficile de trouver des missions pour progresser, mais je trouve ça très simple et ça fait le boulot pour mes projets perso.

mince marco tu m'avais presque convaincu ...
retour à la case départ alors ?

Je te donne un avis pour, donc par honnêteté intellectuelle je te donne aussi un avis contre. Après Eric Elliott n'est pas particulièrement contre l'usage de TypeScript, il dit en gros que le gain n'en vaut pas la dépense grosso modo pour les mêmes raisons que tu avances, c'est à dire que l'écosystème JS est déjà très fourni. Mais je suis moyennement d'accord parce que ça suppose d'aller farfouiller dans beaucoup d'outils différents alors qu'on a beaucoup de choses d'un coup avec TS.

C'est pas son seul argument, cf remarque de Paleo.

Je te fournis aussi ce lien parce qu'il est en plein dans le sujet et que c'est une référence internationale, cette question servira certainement à d'autres lecteurs.

Concernant le débat sur la POO, je suis du même avis que Paleo. L'exemple qu'il a fourni contient une fonction first class, je vois mal comment tu peux considérer ça comme de la POO. La même implémentation en POO partirait d'une classe TextFormatter implémentant une fonction format avec toute une hiérarchie de classes pour mutualiser les mécanismes de formatage.

[Engiwip]

J'ai pas encore regardé TS3.4 mais perso je fais ce genre de choses :

Je te donne un avis pour, donc par honnêteté intellectuelle je te donne aussi un avis contre. Après Eric Elliott n'est pas particulièrement contre l'usage de TypeScript, il dit en gros que le gain n'en vaut pas la dépense grosso modo pour les mêmes raisons que tu avances, c'est à dire que l'écosystème JS est déjà très fourni. Mais je suis moyennement d'accord parce que ça suppose d'aller farfouiller dans beaucoup d'outils différents alors qu'on a beaucoup de choses d'un coup avec TS.
.

l'article que tu as donné est top
vos exemples aussi.
çà donne à réfléchir.

merci à vous deux

pour la POO , il n' y a pas de débat ouvert , çà ne m'interesse absolument pas d'avoir tort ou raison .
on ne cherche pas à piloter un systeme par le langage comme on le ferait en C ou en Go , on ne cherche pas à gerer l'espace d'adressage , faire de l'IOT etc..

,ce sont des objets qu'on manipule , les interfaces permettent de définir un comportement , de pratiquer la composition.
a partir du moment ou tu découples la complexité et que tu définis un comportement de classe ici dans le cas du formatter , on fait de la POO .
pas besoin de se faire un noeud au cerveau , c'est de la POO dès que tu penses à l'application d'un pattern .

et chaque langage moderne implemente plus ou moins bien des paradigmes de POO selon la finalité du langage

pour moi çà commence ici la programmation objet , sinon c'est de la prog systeme voir du scripting bash . bref çà ne m'interesse pas ce débat sur des mots ou sur la philosophie des concepts .
la POO n'est pas que du polymorphisme, , de l' heritage multiple , etc .