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 !

TypeScript 1.5 entre en production
Le sur-ensemble typé de JavaScript disponible dans Visual Studio 2015 et en téléchargement

Le , par yahiko

346PARTAGES

1  0 
TypeScript 1.5 entre en production

Ce lundi 20 juillet, l'équipe TypeScript vient d'annoncer la mise en production de la version 1.5 du langage, trois mois après l'annonce de la version alpha. Ce délai de mise en production relativement long par rapport aux précédentes versions montre le saut à la fois qualitatif et quantitatif opéré par cette version 1.5.

Pour avoir un panorama des nouvelles fonctionnalités, on peut utilement se référer à l'article annonçant la version alpha. Pour rappel, cette version 1.5 ajoute :
  • Une nouvelle syntaxe pour l'importation de modules permettant de choisir plus finement les composants à inclure
  • Les décorateurs, à titre expérimental, développés en collaboration avec Angular, Ember et Aurelia.


Cette version 1.5 précise en outre certains concepts.

Espace de nommage
Les notions assez peu satisfaisantes de "modules internes" et "modules externes" ont été clarifiées.
Les modules internes qui étaient déclarés à l'aide du mot-clé module peuvent désormais être déclarés à l'aide du nouveau mot-clé namespace dans la mesure où cette notion de module interne dans TypeScript rejoint en grande partie celle d'espace de nommage existant dans d'autres langages (C++ ou C# par exemple).

Nouveaux formats de modules
Les modules externes sont quant à eux désormais désignés modules, tout simplement. A noter que TypeScript prend en charge deux nouveaux formats de modules (au sens serveur). En plus de AMD et CommonJS, cette version 1.5 peut générer des modules SystemJS et UMD faisant de TypeScript de plus en plus une boite à outils pour le développement Web et pas uniquement un simple langage.

Centralisation des dépendances de compilation
La déclaration des dépendances externes à un fichier source se faisait jusqu'à présent soit à l'aide de l'instruction ///<reference>, relativement laide il faut bien le dire, ou via la ligne de commande lors de l'appel au compilateur. Il est possible désormais de définir un fichier nommé par défaut tsconfig.json contenant toutes les dépendances nécessaires à la compilation d'un projet.

Prise en charge ES6
Enfin, cette version de production fait un bond considérable dans sa prise en charge de la norme ES6 passant d'une couverture fonctionnelle de 25% lors de la version alpha, à un taux de 52% avec cette version de production, soit plus du double, rejoignant ainsi le pur transpileur ES6 Traceur.

Support de la norme ES6 selon Kangax

Cette version 1.5 est une étape majeure dans l'évolution du langage TypeScript où de nombreux aspects ont été améliorés, tant que le plan de la syntaxe pure que sur le plan de la compilation ou de l'intégration avec d'autres outils ou composants. Des orientations majeures ont été prises comme l'adjonction d'un polyfill pour gérer les décorateurs. Il semblerait que TypeScript se montre plus ambitieux quant à ses objectifs à plus long terme en ne se contentant plus de n'être qu'un langage transpilant vers JavaScript, mais de se positionner comme un point nodal dans le processus de développement Web.

source : Blog officiel de TypeScript

Que pensez-vous des nouveautés apportées par cette nouvelle version de TypeScript ?

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

Avatar de youtpout978
Expert confirmé https://www.developpez.com
Le 22/07/2015 à 9:40
Citation Envoyé par alves1993 Voir le message
Assez important .

Vraiment TypeScript !!!! J'imagine le Web dans 5 ans (Dart vs TypeScript vs Javascript vs autre chose) se sera vraiment cool et concurrentiel .
On aura peut être WebAssembly d'ici là.
1  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 22/07/2015 à 11:18
Citation Envoyé par Zefling Voir le message
Pour l'instant ça se profile plus vers un Javascript vs WebAssembly.
Citation Envoyé par youtpout978 Voir le message
si on peut faire directement du c# typescript n'a plus de raison d'être, et de ce que j'en ai compris on pourra communiquer entre JS et WebAssembly dans un premier temps mais à terme la compatibilité pourra être cassé pour que WebAssembly supplante JS.
JavaScript est concurrent de WebAssembly, comme PHP est concurrent des modules PHP codés en C++.
1  0 
Avatar de Aeson
Nouveau Candidat au Club https://www.developpez.com
Le 22/07/2015 à 23:24
Pour gérer le DOM, le JS est parfaitement adapté, et pour ça il y a peu de chance que ça change.
Pour rappel le TypeScript devient du javascript une fois compilé. Le browser ne voit pas (encore) le TypeScript. Donc comparer le Javascript et le TypeScript n'a pas vraiment de sens (A part pour la productivité de développement qui est bien meilleur en TypeScript)

Ce qui pourrait (et qui fera a mon avis) faire abandonné le Javascript c'est ca :
http://javascript.developpez.com/actu/82363/Chrome-pourrait-interpreter-nativement-TypeScript-le-projet-SoundScript-a-pour-but-un-mode-plus-fort-pour-le-JavaScript/

Si le browser pourrait interpréter directement du TypeScript ca devrait apparemment augmenter les performances.
1  0 
Avatar de Aeson
Nouveau Candidat au Club https://www.developpez.com
Le 22/07/2015 à 23:30
Les développeurs Web par facilité continueront de toute façon à utiliser ce langage permissif. La loi du moindre effort hélas...
Quand ils auront conscience de tous le temp qu'ils perdent a debugger du JavaScript qui est une vraix passoir ils feront des yeux. Perso c'est TypeScript direct et le moins de logique possible dans les contrôleurs. D’abord dans le Backend ou dans les Directives Angular et si c'est pas possible autrement alors dans le Js/Ts.

Et depuis je jure beaucoup moins souvent et je suis beaucoup plus productif.
1  0 
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 27/07/2015 à 18:03
Citation Envoyé par yahiko Voir le message
le typage des données est une bonne chose (il y a 15 ans, je n'aurai jamais imaginer devoir enfoncer cette porte ouverte tellement ça me paraît une évidence, mais il faut croire que JavaScript a réussi à faire régresser les mentalités sur ce point...)
JavaScript est typé, tous les langages fournissent des types de base. Il n'y a pas de débat sur le typage en soi mais sur le typage tel que l'apporte TypeScript, c'est-à-dire un typage statique explicite. Le typage dynamique a des cas d'utilisations légitimes, d'où le type Any en TypeScript. Le duck-typing peut également s'avérer très utile, par exemple pour parser des structures d'objets composés à partir d'une description sérialisée comme un JSON. Il n'y a donc pas de solution unique et parfaite, chacun des choix de typage a ses avantages et ses inconvénients. Le mieux est encore d'avoir le choix, et TypeScript est assez souple là-dessus.

Il n'y a pas de régression de mentalités, juste des adeptes qui considèrent leurs choix techniques comme unique vérité: "le typage dynamique c'est une idée à la con", "le typage statique ça sert à rien" etc... . Et c'est valable pour pleins d'autres sujets en informatique, les paradigmes de programmation, les conventions de code...
1  0 
Avatar de Paleo
Membre éclairé https://www.developpez.com
Le 28/07/2015 à 19:31
Citation Envoyé par SylvainPV Voir le message
Ici c'est une assertion donc on pourrait dire que ça sort du cadre du typage, mais je pourrais trouver un autre exemple où les ID deviennent des String et non plus des nombres.
Oublions les classes car elles appartiennent à ES6 et non à TypeScript. Prenons les identifiants number vs string. Admettons que nous ayons deux fonctions qui prennent presque le même type d'objet en paramètre. Nous pouvons procéder ainsi :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
interface Person {
	id: number;
	name: string;
}
interface PersonVariant {
	id: string;
	name: string;
}
function f1(p: Person) {
	p.id; // autocompletion: id is a number
}
function f2(p: PersonVariant) {
	p.id; // autocompletion: id is a string
}
let p: any = {
	id: 12,
	name: 'John'
}; // nous utilisons le type "any" afin d'annuler la définition par inférence
f1(p);
p.id = '12';
f2(p);
Je l'ai écrit plus haut : TypeScript est un mécanisme comparable à JSDoc, en beaucoup plus puissant et réutilisable. Il ne contrôle que le contrat que nous lui donnons à valider. Et l'outil le plus souple pour définir ce contrat, c'est l'interface.
1  0 
Avatar de alves1993
Membre éclairé https://www.developpez.com
Le 21/07/2015 à 21:27
Que pensez-vous des nouveautés apportées par cette nouvelle version de TypeScript ?
Assez important .

Il semblerait que TypeScript se montre plus ambitieux quant à ses objectifs à plus long terme en ne se contentant plus de n'être qu'un langage transpilant vers JavaScript, mais de se positionner comme un point nodal dans le processus de développement Web.
Vraiment TypeScript !!!! J'imagine le Web dans 5 ans (Dart vs TypeScript vs Javascript vs autre chose) se sera vraiment cool et concurrentiel .
0  0 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 22/07/2015 à 9:51
Pour l'instant ça se profile plus vers un Javascript vs WebAssembly.

Parce que Dart et TypeScript, au final ça sera juste pour compiler du JS ou du WA. Dart n'a jamais fonctionné en dehors de Chrome et c'est mal parti pour que ça change.
0  0 
Avatar de youtpout978
Expert confirmé https://www.developpez.com
Le 22/07/2015 à 9:52
Citation Envoyé par Zefling Voir le message
Pour l'instant ça se profile plus vers un Javascript vs WebAssembly.

Parce que Dart et TypeScript, au final ça sera juste pour compiler du JS ou du WA. Dart n'a jamais fonctionné en dehors de Chrome et c'est mal parti pour que ça change.
Surtout que google fait partit des promoteurs de WebAssembly
0  0 
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 22/07/2015 à 10:26
Il n'y a pas vraiment d'opposition entre JavaScript et WebAssembly. WebAssembly est une évolution logique (voire inévitable) de asm.js, passant du format texte en format binaire/bytecode, beaucoup plus rapide à interpréter.

Le fait que WebAssembly puisse se généraliser avec la collaboration des principaux éditeurs de navigateurs est de toute façon une bonne nouvelle pour TypeScript puisque cela enlèvera un argument aux zélotes de JavaScript qui ne supportent pas qu'il y ait une phase de compilation entre le code source et l'exécution dans le navigateur.

WebAssembly aidera aussi à propager l'idée que le typage des données est une bonne chose (il y a 15 ans, je n'aurai jamais imaginer devoir enfoncer cette porte ouverte tellement ça me paraît une évidence, mais il faut croire que JavaScript a réussi à faire régresser les mentalités sur ce point...)

Comme personne n'écrira nativement en WebAssembly, il faudra passer par un langage tiers de plus haut niveau. Aujourd'hui le langage C++ est privilégié pour la phase de prototype. Mais il est tout à fait envisageable de voir TypeScript un jour se compiler en WebAssembly, notamment parce qu'il intégre déjà cette notion de typage indispensable à WebAssembly (ou à asm.js d'ailleurs).
0  0