Microsoft annonce la version 1.5 alpha de TypeScript

Destructuration, compatibilité ES5/ES3 et décorateurs sont au programme

Le 2015-04-02 20:28:19, par yahiko, Rédacteur/Modérateur

Microsoft annonce la version 1.5 alpha de TypeScript
Affectation par décomposition, compatibilité ES5/ES3 et décorateurs

Sur son blog officiel, l'équipe TypeScript vient d'annoncer la disponibilité de la version 1.5 alpha de son langage, surensemble typé de JavaScript.

De nombreuses fonctionnalités ont été ajoutées par rapport à la version précédente, notamment au niveau du support de la nouvelle norme ECMAScript 6 (qui devrait selon toute vraisemblance être adoptée officiellement au mois de juin).

Modules
C'est le cas par exemple des modules où il sera désormais possible d'importer sélectivement certaines portions d'un module (une classe en particulier ou une fonction par exemple).

Code :

1
2
import * as Math from "my/math";
import { add, subtract } from "my/math";

L'ancienne syntaxe concernant les modules, import en particulier, reste valide mais devrait à terme être dépréciée.

Affectation par décomposition (destructuring)
Cette possibilité syntaxique présente entre autres en Python et en Ruby, est également une fonctionnalité ES6 qui est implémentée dans la version 1.5 de TypeScript. Cela permet de rendre le code plus concis et plus clair quand à l'intention du développeur en se passant de variables temporaires.

Code :

1
2
var [x, y] = [10, 20];
[x, y] = [y, x];  // a simple swap

Grâce à cette technique il est également possible de se passer du nommage explicite d'un objet passé en argument d'une fonction :

Code :

1
2
3
4
5
var myClient = {name: "Bob", height: 6};
function greetClient({name, height: howTall}) {
  console.log("Hello, " + name + ", who is " + howTall + " feet tall.");
}
greetClient(myClient);

Compatibilité ES5 et ES3
Certaines nouvelles fonctionnalités de la version 1.4 qui n'étaient compatibles qu'en ciblant du JavaScript ES6 telles que l'interpolation de chaînes (template strings), let ou const sont désormais compatibles avec une génération JavaScript en ES5 et ES3.

Notons également l'introduction d'une nouvelle syntaxe de boucle for..of permettant d'itérer plus simplement sur les éléments d'une collection et non pas sur leur clé comme c'est actuellement le cas de for..in.

Décorateurs
Mais la grande nouveauté et surprise (car non inscrite à la feuille de route initiale) de cette version 1.5 est l'apparition des décorateurs issus en particulier du framework applicatif Angular. Cette collaboration entre Microsoft et Google a suffisamment défrayé la chronique pour que vous en ayez entendu parler.

Code :

1
2
3
4
5
6
7
8
9
10
class Person {
  @memoize
  get name() { return `${this.first} ${this.last}` }

  set name(val) {
    let [first, last] = val.split(' ');
    this.first = first;
    this.last = last;
  }
}

Ici, le décorateur @memoize indique au compilateur TypeScript que les getter et setter sont à mettre en cache.

À mettre également au crédit du rapprochement avec les frameworks MVC, TypeScript supportera la notion de computed properties, permettant de simplifier l'initialisation des objets aux propriétés dynamiques.

API
L'API du compilateur n'est pas en reste et propose de nouveaux services, mis en vitrine dans un plugin développé pour l'occasion pour l'éditeur Sublime Text.

Cette API doit permettre à n'importe quel éditeur ou EDI de reconnaître la syntaxe de TypeScript et proposer de puissantes fonctionnalités de formatage et de refactoring sans développements significatifs. Ceci évidemment dans le but d'améliorer le support et la diffusion de ce langage.

TypeScript se détache ainsi un peu plus de Visual Studio, sa matrice d'origine, en supportant de plus un fichier projet indépendant, tsconfig.json, au format JSON exploitable par n'importe quel éditeur et EDI.

source : Blog officiel de l'équipe TypeScript

Et vous ?
Avez-vous déjà essayé cette version 1.5 alpha ?
Que pensez-vous des nouveautés proposées ?

Discussion forum

13 commentaires

sitexw
Membre régulier

La seule chose que je trouve "dommage" pour le moment, est le fait qu'il n'existe pas de machine virtuelle pour TypeScript de la même façon pour JavaScript avec NodeJS.
Car toutes les fonctionnalités que TS apporte sont converti en JS avec au passage une perte de performance plus ou moins importante.
Et que les fonctionnalités qui pourraient apporter de meilleure performance, comme le typage des variables n'existe pas sur Javascript.

Je suis largement pour la progression de TypeScript (surtout en back), mais comment se projeter dans l'avenir avec un "langage" qui sera toujours limité par d'autre éléments (machine virtuelle, performance, ...).
Je me vois pas dans 2 ans continuer à convertir mes lignes de code TS en JS à chaque fois que je fais un CTRL+S.

le 03/04/2015 à 14:24
mangobango
Membre averti

Incroyable, mais là, j'aime Microsoft Le langage commence à mûrir sympathiquement.

le 03/04/2015 à 12:36
yahiko
Rédacteur/Modérateur

Envoyé par sitexw

La seule chose que je trouve "dommage" pour le moment, est le fait qu'il n'existe pas de machine virtuelle pour TypeScript de la même façon pour JavaScript avec NodeJS.
Car toutes les fonctionnalités que TS apporte sont converti en JS avec au passage une perte de performance plus ou moins importante.
Et que les fonctionnalités qui pourraient apporter de meilleure performance, comme le typage des variables n'existe pas sur Javascript.

Je suis largement pour la progression de TypeScript (surtout en back), mais comment se projeter dans l'avenir avec un "langage" qui sera toujours limité par d'autre éléments (machine virtuelle, performance, ...).
Je me vois pas dans 2 ans continuer à convertir mes lignes de code TS en JS à chaque fois que je fais un CTRL+S.

C'est une vraie problématique que tu soulèves là.

Maintenant, TypeScript a résolument choisit la voie de la modestie par rapport à JavaScript.
Et je n'ai pas l'impression que Microsoft soit décidé à faire le premier pas ou à forcer l'usage en natif de TypeScript dans les navigateurs ou côté serveur avec Node.js par exemple.

Cependant, à un moment donné, l'industrie va quand même devoir prendre ses responsabilités vis-à-vis de JavaScript qui commence ou va commencer à devenir davantage un problème qu'une solution, notamment par rapport aux problèmes de performances, de scalabilité et de fiabilité du code.

Google réfléchit déjà à introduire TypeScript ou une variante dans son moteur V8 de Chrome (cf. Chrome pourrait interpréter nativement TypeScript).
Si cela se concrétise en production, nous pourrions voir un basculement bien plus important vers TypeScript que cela ne s'est produit jusqu'à présent, en incluant les récentes annonces d'Angular.

Si l'industrie choisit le status quo avec un JavaScript seul langage universel côté navigateur, et connaissant tous les inerties dans le domaine, c'est tout à fait possible, alors TypeScript devra se contenter d'un rôle de supplétif face à JavaScript même s'il devrait continuer à se diffuser dans la communauté des développeurs (surtout ceux qui codent autre chose que des scripts de 10 lignes). Dans ce cas, TypeScript sera tout de même LE surensemble de JavaScript, un peu ce que le C++ est au C à l'heure actuelle, ce qui n'est déjà pas mal ! ^^

le 03/04/2015 à 14:37
Paleo
Membre éclairé

Envoyé par sitexw

La seule chose que je trouve "dommage" pour le moment, est le fait qu'il n'existe pas de machine virtuelle pour TypeScript de la même façon pour JavaScript avec NodeJS.
Car toutes les fonctionnalités que TS apporte sont converti en JS avec au passage une perte de performance plus ou moins importante.
Et que les fonctionnalités qui pourraient apporter de meilleure performance, comme le typage des variables n'existe pas sur Javascript.

Pour le moment, le JavaScript est le bytecode de TypeScript. La VM est donc celle de JavaScript.

Il n'y a aucune perte de performance lors de la compilation du code TS vers du JS. Il suffit de regarder le code JS généré pour s'en convaincre. Écrire du code JS directement ne permet pas d'obtenir de meilleures performances qu'en écrivant du code TS, en fait, le compilateur TS produit un code on ne peut plus propre.

En revanche, il serait peut-être possible de faire encore mieux que JS. Yahiko avait publié un article sur des optimisations à l'exécution qui pourraient être faites à l'aide du typage, sur Chrome. C'est engageant, mais rappelons-nous que Google éparpille ses efforts parfois inutilement. Aujourd'hui toutes les équipes sont concentrées sur l'implémentation de EcmaScript 6, et, en ce qui concerne les VM, EcmaScript reste donc la seule valeur sûre des deux prochaines années.

Envoyé par sitexw

Je me vois pas dans 2 ans continuer à convertir mes lignes de code TS en JS à chaque fois que je fais un CTRL+S.

Allons bon. Un compilateur n'est pourtant pas une hérésie, dans la programmation.

le 03/04/2015 à 16:10
Paleo
Membre éclairé
Envoyé par yahiko

Pas vraiment puisque le code JavaScript est également du code TypeScript. Une seule VM TS suffirait en principe pour faire tourner tout le Web.

Pas tout à fait.
Par exemple ce code passe en JavaScript mais est invalide en TypeScript :
Code :
```
1
2
var s = 'abc';
s = 123; // <- ici erreur de typage en TypeScript
```
Le compilateur TS génère, malgré l'erreur, le code JavaScript attendu. Et c'est pourquoi l'on peut réellement renommer un fichier ".js" en fichier ".ts" et travailler dessus directement. Il n'en reste pas moins que les erreurs de typages sont invalides en TypeScript. Mais c'est vrai qu'une même VM pourrait avoir un mode d'exécution supplémentaire, comme le "use strict;" en est un.
le 03/04/2015 à 16:18
Zefling
Expert confirmé

Ça voudra dire qu'il faudra faire marcher les 2 VM (JS et TS) en même temps pour qu'elles puissent discuter ensemble. C'est peut-être ça qui bloque ?

le 03/04/2015 à 15:23
yahiko
Rédacteur/Modérateur
Envoyé par Tarh_

Pas tout à fait.
Par exemple ce code passe en JavaScript mais est invalide en TypeScript :

Code :

1
2
var s = 'abc'; s = 123; // <- ici erreur de typage en TypeScript

Le compilateur TS génère, malgré l'erreur, le code JavaScript attendu. Et c'est pourquoi l'on peut réellement renommer un fichier ".js" en fichier ".ts" et travailler dessus directement. Il n'en reste pas moins que les erreurs de typages sont invalides en TypeScript. Et d'ailleurs il reste à prouver que des optimisations liées au typage seraient encore possibles si les erreurs de typage étaient tolérées.
Au moins un qui connaît le langage
On est d'accord. Cependant, selon les réglages de la VM TS, ce code peut ne pas être bloquant. Le programme peut continuer sa progression.
le 03/04/2015 à 16:23
Paleo
Membre éclairé

Oui, j'ai édité, c'est vrai qu'une même VM pourrait être utilisée sur du code typé et non typé.

Mais je me demande s'il serait intelligent d'embarquer toutes les infos de typage dans le code exécutable. Les définitions d'interfaces et les précisions de typage prennent de la place. Le fait qu'elles soient supprimées dans le code compilé est un gain de performance, au moins pour le temps de téléchargement du code vers le navigateur.

le 03/04/2015 à 16:25
yahiko
Rédacteur/Modérateur

Je pense qu'une VM TS réellement utilisable dans le monde réel du Web, où l'exécutabilité doit primer sur la validité du code, le typage ne doit pas être une cause de plantage.

Cependant, si le code et son typage sont consistants, il serait dommage de s'en priver, surtout pour indiquer certaines optimisations au compilateur.

Autrement dit, en cas de conflit au niveau du typage, le bytecode résultant devrait supprimer le typage (ou utiliser le type any) et donc considérer les objets manipulés comme des pointeurs vers des emplacements mémoires (structures {...} ou chaînes de caractère).

Si le typage est consistant et permet des optimisations, dans ce cas, le bytecode se devrait de conserver l'information sur les types, en particulier le type number pour les calculs et par conséquent considérer les objets manipulés comme des valeurs.

le 03/04/2015 à 16:41
Vlozer
Membre habitué

Envoyé par Zefling

Ça voudra dire qu'il faudra faire marcher les 2 VM (JS et TS) en même temps pour qu'elles puissent discuter ensemble. C'est peut-être ça qui bloque ?

En ce qui concerne Blink, ils disaient que techniquement ce n'etait pas un probleme insurmontable de faire cohabiter dart et js (qui sont beaucoup plus heterogene), mais ils attendaient que le nouveau GC OilPan soient terminé ce qui aurait (selon eux) tres largement simplifié l'implémentation d'autres langages aux coté de JS.

le 03/04/2015 à 19:03

Poster une réponse