Typescript hors angular pour quelle utilisation ?

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� ?

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"

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.

Citation:

---

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

Citation:

---

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.

Citation:

---

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.

Citation:

---

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 ;)

Citation:

---

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.

Citation:

---

Envoy� par 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� ?

---

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.

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

Citation:

---

Envoy� par Marco46

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

Citation:

---

Envoy� par Marco46

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.

Citation:

---

Envoy� par Marco46

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

Citation:

---

Envoy� par Marco46

�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

Citation:

---

Envoy� par Marco46

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

Bonjour ,
je tente une r�ponse.

Citation:

---

Envoy� par Paleo

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

Citation:

---

Envoy� par Paleo

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 .

Citation:

---

Envoy� par Paleo

� 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 ?

Citation:

---

Envoy� par Paleo

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?

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Engiwip

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 ?

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Engiwip

ok donc je ne vois pas d'utilit� � prendre TypeScript

---

Alors tu ne vois pas non plus celle de flow ?

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Paleo

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.

Citation:

---

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 ?

Citation:

---

Envoy� par Paleo

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

Citation:

---

Envoy� par Marco46

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.

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Engiwip

?
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:

---

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; }

---

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

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.

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.

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Paleo

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.

Citation:

---

Envoy� par 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.

---

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

Citation:

---

Envoy� par 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.

---

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

Code:

---

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.

Citation:

---

Envoy� par Engiwip

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.

Citation:

---

Envoy� par Marco46

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 .