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 .
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.
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.Je n ai pas trouvé l utilité des patterns oop de typescript.
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).
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.Au final Ca rajoute une couche de transpilation donc de complexite en plus.
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.
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.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.
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.
Les exemples que je t'ai cité (Vue3, deno, ...) semblent montrer que si.En fait je ne suis pas convaincu que Typescript s inscrive dans la durée pour que ca devienne un choix incontournable .
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.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.
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.
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.
ok donc je ne vois pas d'utilité à prendre TypeScript
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.
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à çà.
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
Ok çà a le merite d'etre clair
Bonjour ,
je tente une réponse.
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
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 .
bah un peu quand meme ,constructor , class , interface , generic c'est un peu de l'OOP non ?
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?
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.
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 ?
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.
Alors tu ne vois pas non plus celle de flow ?
Oui tu peux.
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.
Sauf que tu inverses les termes. Le leader c'est très clairement TypeScript.
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.
ok Tout ceci m'eclaire profondement .merci.
bonne question.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 ?
du coup j'en ai une autre : est ce que les dev du projet nodejs ambitionnent de tout réecrire en typescript ?
?
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
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.
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; }
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.
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.
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.
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.Envoyé par Engiwip
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.
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 .
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager