IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Microsoft annonce la version 1.5 alpha de TypeScript
Destructuration, compatibilité ES5/ES3 et décorateurs sont au programme

Le , par yahiko

27PARTAGES

7  0 
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 : Sélectionner tout
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 : Sélectionner tout
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 : Sélectionner tout
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 : Sélectionner tout
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 ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de sitexw
Membre régulier https://www.developpez.com
Le 03/04/2015 à 14:24
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.
3  0 
Avatar de mangobango
Membre averti https://www.developpez.com
Le 03/04/2015 à 12:36
Incroyable, mais là, j'aime Microsoft Le langage commence à mûrir sympathiquement.
1  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 03/04/2015 à 14:37
Citation Envoyé par sitexw Voir le message
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 ! ^^
1  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 03/04/2015 à 16:10
Citation Envoyé par sitexw Voir le message
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.

Citation Envoyé par sitexw Voir le message
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.
1  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 03/04/2015 à 16:18
Citation Envoyé par yahiko Voir le message
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 : Sélectionner tout
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.
1  0 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 03/04/2015 à 15:23
Ç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 ?
0  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 03/04/2015 à 16:23
Citation Envoyé par Tarh_ Voir le message
Pas tout à fait.
Par exemple ce code passe en JavaScript mais est invalide en TypeScript :

Code : Sélectionner tout
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.
0  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 03/04/2015 à 16:25
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.
0  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 03/04/2015 à 16:41
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.
0  0 
Avatar de Vlozer
Membre habitué https://www.developpez.com
Le 03/04/2015 à 19:03
Citation Envoyé par Zefling Voir le message
Ç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.
0  0