Discussion :

[Paleo]

« TypeScript, le langage compilé en JavaScript ? Mais pourquoi faudrait-il quitter JavaScript ? »

Le langage JavaScript ne manque pas d'atouts et le mieux est souvent l'ennemi du bien. Délaisser ce qui fonctionne est un risque. Et puis il existe de solides arguments en défaveur des langages construits sur JavaScript, examinons-les :

• la question de la pérennité des syntaxes non standard ;
• la problématique de l'intégration avec l'existant ;
• la difficulté de former ou de trouver les développeurs.

Je répondrai à ces trois questions au fil de l'exposé tout en situant TypeScript par rapport aux technologies concurrentes. Je tenterai ensuite de donner envie au lecteur d'essayer.

Lisez la suite de l'article : Pourquoi utiliser TypeScript.

Voici le sommaire :

I. TypeScript est un choix sans risque
II. Faire coopérer TypeScript et JavaScript ?
III. La syntaxe TypeScript est pérenne
IV. TypeScript et Microsoft ?
V. La programmation orientée objets et TypeScript
VI. Les interfaces TypeScript
VII. Typage statique ?
VIII. Comment démarrer avec TypeScript
IX. Remerciements

Vos réactions seront les bienvenues.

[SylvainPV]

+1 pour l'excellent IDE qu'est WebStorm. Mais c'est amusant que tu le mentionnes, car c'est aussi la raison pour laquelle je n'ai pas essayé TypeScript pour l'instant. En effet, pour peu qu'on ait pris la bonne habitude de documenter ses fonctions, WebStorm se charge de vérifier les types : http://blog.jetbrains.com/webide/201...s-annotations/

Du reste, je préfère les prototypes aux classes et aux interfaces, donc TypeScript ne m'apportait finalement rien. Mais je pense que ça doit attirer beaucoup plus les développeurs Java.

[Paleo]

Mais je pense que ça doit attirer beaucoup plus les développeurs Java.

Et les développeurs PHP aussi.

[Bovino]

Article intéressant et très clair !



Néanmoins, je trouve que certains points sont sujets de débat...

D'une part, je rejoins SylvainPV concernant les prototypes, mais c'est peut-être l'habitude de les utiliser.

Ensuite

Un mécanisme sert à émuler un comportement de classe : le prototype dont l'usage est malheureusement verbeux, affreusement moche et incomplet.

Trouver le modèle de POO par prototype de JavaScript moche et incomplète, c'est un avis et tu as raison de donner ton avis (et je suis conscient que tu n'es pas isolé ) mais je vois mal en quoi il te parait verbeux...
Peut-être veux-tu juste parler de certains de ses aspects, comme par exemple l'héritage où effectivement, en plus d'être lurd et verbeux, c'est surtout fastidieux !
Surtout, il n'est pas destiné, sauf erreur grossière de ma part, à émuler un comportement de classe, au contraire, il propose une autre façon de considérer la POO.

Impossible en particulier de déclarer des membres privés dans le prototype.

Effectivement, ça n'aurait d'ailleurs pas de sens puisqu'un prototype est un objet commun à toutes les instances de l'objet, d'ailleurs, toute modification du prototype impacte toutes les instances de l'objet, y compris celles déjà existantes. Pour créer des membres privés, il faut le faire au niveau de l'instance.

Mais encore une fois, ces considérations sont sujettes à débat !

EDIT :

+1 pour l'excellent IDE qu'est WebStorm.

+2 alors !

[Paleo]

Trouver le modèle de POO par prototype de JavaScript moche et incomplète, c'est un avis et tu as raison de donner ton avis (et je suis conscient que tu n'es pas isolé ) mais je vois mal en quoi il te parait verbeux...
Peut-être veux-tu juste parler de certains de ses aspects, comme par exemple l'héritage où effectivement, en plus d'être lurd et verbeux, c'est surtout fastidieux !

L'héritage non et d'ailleurs le plus souvent l'héritage est une fausse bonne idée ().

C'est juste que, lorsqu'on raisonne sur des classes (c-à-d des objets faits dans le même moule), on doit écrire le prototype puis une éventuelle fonction "factory" qui produit l'instance en lui affectant le prototype, en JS il y a mille manières de le faire alors qu'il devrait y en avoir zéro puisque c'est au langage de faire ça. Plus les répétitions des ".prototype." pour déclarer les membres, je sais, c'est évitable mais en pratique on n'évite pas. Comparez dans le Playground le code TS au code JS généré : malgré les informations de typage en plus, dont une interface, le code TS est plus court et plus lisible.

De toute manière ES6 règlera ce point.

Surtout, il n'est pas destiné, sauf erreur grossière de ma part, à émuler un comportement de classe, au contraire, il propose une autre façon de considérer la POO.

Tiens c'est vrai ça, c'est une erreur de ma part. J'aurais dû écrire qu'il "peut servir" et non qu'il "sert".
Tout à fait juste.

Effectivement, ça n'aurait d'ailleurs pas de sens puisqu'un prototype est un objet commun à toutes les instances de l'objet, d'ailleurs, toute modification du prototype impacte toutes les instances de l'objet, y compris celles déjà existantes. Pour créer des membres privés, il faut le faire au niveau de l'instance.

Des méthodes privées auraient pourtant du sens.

[SylvainPV]

De toute manière ES6 règlera ce point.

Tu veux parler du keyword "class" ? De mon point de vue, il ne règle rien du tout, au contraire il ajoute une énième façon de faire de la programmation objet en JavaScript, en perdant les avantages des prototypes.

Le code présenté sur le typescript playground reprend le pattern classique (fonctions et opérateur new) et non le pattern prototype pur (objets et Object.create). Voilà ce que ça donnerait en prototypes :

Code :

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

1
2
3
4
5
6
7
8
9
var Greeter = {  
  greeting: "anonymous",
  greet: function () {
    return "Hello, " + this.greeting;
  }
};
 
var greeter = Object.create(Greeter);
greeter.greeting = "world";

Personnellement je trouve ça tout aussi clair. Mais ça reste un débat

[Paleo]

Merci pour l'exemple, je n'ai encore jamais utilisé Object.create(), compatibilité avec IE8 oblige. Mais à mort IE8 ! Néanmoins je trouve peu élégante la double existence de la variable "greeting" au niveau du prototype et au niveau de l'instance.

Par certains côtés ce débat me fait penser à celui du C versus le C++.

[jolt-counter]

Bon article,

par contre je rebondis sur un point.

Pas besoin d'un IDE pour coder en TypeScript.

Perso j'avais commencé à coder en TypeScript en 2013 avec Vim et la ligne de commande. Pour Vim, Emacs, Notepad++ et sans doute d'autres simple éditeurs de texte, il existe des plugins pour avoir la coloration syntaxique de TypeScript.
D'ailleurs pour bien se familiariser avec la compilation de TypeScript vers JavaScript, je recommande de commencer par la ligne de commande sans utiliser de fichier de configuration comme tsconfig.json.

Sinon, un bon IDE gratuit, léger et multiplateforme supportant très bien le TypeScript est Visual Studio Code, je le recommande grandement.

[Paleo]

Bonjour jolt-counter, merci pour le retour positif.

Je suis également passé à Visual Studio Code pour les projets TypeScript et/ou JavaScript. Mon article date un peu. En 2014, cet excellent éditeur n'existait pas.