IdentifiantMot de passe
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 se rapproche de sa version 1.0
Microsoft dévoile la feuille de route de son alternative à JavaScript

Le , par Stéphane le calme
69 commentaires

224PARTAGES

2  0 
TypeScript, le préprocesseur JavaScript fait par Anders Hejlsberg, père du C#, et soutenu par la branche Open Source de Microsoft se rapproche progressivement de sa version 1.0. A cet effet, l'entreprise a décidé de de proposer un téléchargement séparé pour TypeScript dans Visual Studio contrairement à la version 0.9.1.1 qui faisait partie intégrante de Visual Studio 2013 RC.

L'option d'installation pourra donc être trouvée comme un lien dans Visual Studio lors de la création d'un nouveau projet. Mais TypeScript sera aussi disponible en téléchargement direct.

Sans pour autant en préciser les dates butoirs, Microsoft a dévoiler sa feuille de route. L'entreprise prévoit la version 0.9.5 qui améliorera l'utilisation de la mémoire et du CPU et mettra également un accent sur la correction des problèmes signalés par les utilisateurs. Par la suite une RC de 1.0 verra le jour et apportera les derniers correctifs à la stabilité et à la conformité avec les spécifications de 1.0. Enfin la version finale 1.0 sera lancée.

Les avantages que le langage apporte par rapport à JavaScript sont entre autre la gestion des classes et des modules (POO), le typage fort optionnel ( meilleure détection d'erreurs et meilleure auto-completion ) ou encore la gestion des arguments et de leurs valeurs par défaut.

Télécharger Typescript

Source : Blog MSDN

Et vous ?

Avez-vous déjà utilisé TypeScript ou une toute autre alternative à JavaScript ?

Quels sont les points qui vous séduisent le plus ?

Pouvez-vous identifier les faiblesses du langage ou les difficultés que vous avez rencontré lors de son utilisation ?

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

69 commentaires
Commenter Signaler un problème
DelphiManiac
Avatar de DelphiManiac
Membre émérite https://www.developpez.com
Le 04/04/2014 à 18:27
Citation Envoyé par jojosbiz Voir le message
Totalement inutile ces histoires de Typescript, Coffeescript, Dart (sans la VM), typage fort, etc...si c'est pour pondre du javascript au final.

Cette maladie moderne de vouloir toujours rajouter des couches par dessus les couches...

Peignez des rayures sur un âne, ça restera un âne, ça ne deviendra pas un zèbre !
Totalement inutile ces C, C++, Delphi, C#, VB, Python, Php, ... (la liste pourrait être longue) si c'est pour pondre du code machine à la fin, autant coder directement en code machine et en binaire. Je ne parle même pas de l'assembleur qui n'est là que pour les fainéants qui ne mémorise pas la valeur binaire de chaque instruction processeurs. Rien ne vaut un bon JMP, JNE ou JE, oups pardon je suis trop haut niveau là (11101011, 01110101, 01110100).

Tu as vu, moi aussi je peut dire des grosses bêtises.
11  0 
DonQuiche
Avatar de DonQuiche
Expert confirmé https://www.developpez.com
Le 04/04/2014 à 15:31
Citation Envoyé par jojosbiz Voir le message
Totalement inutile ces histoires de Typescript, Coffeescript, Dart (sans la VM), typage fort, etc...si c'est pour pondre du javascript au final.
Le typage fort réduit la fréquence des bogues et permet de meilleurs outils. Ceci est objectif, indiscutable et très significatif. On peut en revanche débattre de son impact sut la productivité, c'est une autre affaire, fonction de la taille et de la nature du projet, et sujette à débat. Mais qualifier le typage fort de "totalement inutile"... Tu parlais d'âneries il me semble ?
6  1 
ptah35
Avatar de ptah35
Membre éclairé https://www.developpez.com
Le 05/04/2014 à 11:27
Citation Envoyé par jojosbiz Voir le message
Si on raisonne par l'absurde, tu as raison, c'est évident.

Mais comparer Typescript (c'est le sujet, je le rappelle) avec des langages à part entière, c'est une ânerie au moins aussi grosse que la mienne...
Même si je concède qu'il faut bien qu'un langage soit écrit avec un autre (PHP est écrit en C par exemple).

Donc puisque tu compares TypeScript à des langages et pour rester dans le Javascript, tu vas p-e finir par dire que JQuery est un langage ?

Moi aussi, je peux faire des raisonnements par l'absurde
Je ne pense pas qu'il ait là un raisonnement par l'absurde. La comparaison me parait pertinente. Javascript, qu'on le veuille ou non est le seul langage supporté par la quasi-totalité des navigateurs et comme il est peu probable que cela change dans un avenir proche, il faut bien faire avec. Mais "faire avec" signifie seulement que le programme téléchargé par le navigateur doit être écrit en Javascript, cela ne signifie pas que le développeur de ce programme soit obligé de le rédiger dans ce langage.

Typescript, Coffeescript, Java (avec GWT) sont des langages de programmation à part entière qui peuvent être compilés en Javascript (un autre langage de programmation à part entière). La compilation en Javascript n'a d'ailleurs rien de particulier et ces langages peuvent --- et de fait, certain le sont --- être compilés dans d'autres langages. La compilation consiste à utiliser un programme pour traduire un programme écrit dans un langage source en un programme équivalent écrit dans un langage cible; le langage cible ne doit pas forcément être un langage machine. (A ce propos, le PHP qui est écrit en C n'est pas le langage, mais le programme de traduction et/ou d'exécution.)

Je n'ai rien contre Javascript et j'ai plaisir à développer avec ce langage, mais je conçois volontiers que d'autres aient un avis différent et il n'y a aucune raison pour que ceux-ci soient obligés d'utiliser ce langage. En outre, même lorsque le développement se fait en Javascript, le programme source (écrit pour être lu par des humains) est rarement le même que celui qui est exécuté par le navigateur qui aura très probablement subit, au moins, une "minification". Si on peut faire confiance à un programme qui transforme un programme Javascript en un programme Javascript "minifié", pourquoi ne pas faire confiance à un programme qui transforme un programme en langage X en un programme Javascript ("minifié" ou non).
5  0 
yahiko
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 25/10/2013 à 0:57
Juste à titre informatif, j'ai rédigé une introduction succincte sur ce langage ici : http://www.developpez.net/forums/d13...ge-typescript/
3  0 
tomlev
Avatar de tomlev
Rédacteur/Modérateur https://www.developpez.com
Le 05/04/2014 à 10:59
Citation Envoyé par jojosbiz Voir le message
Donc puisque tu compares TypeScript à des langages et pour rester dans le Javascript, tu vas p-e finir par dire que JQuery est un langage ?
Je ne vois pas le rapport. TypeScript est un langage (qui est "transpilé" en JS, au même titre que CoffeeScript par exemple), alors que jQuery est une bibliothèque.
3  0 
Traroth2
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 22/10/2013 à 14:04
Citation Envoyé par elmcherqui Voir le message
Typescript n'est pas un nouveau langage destiné a corriger les defaut de javascript , mais tous simplement la version Ecmascript 6 de javascript.
Typescript nous permet de profiter aujourdhui de la version ecmascript 6 de javascript en attendant qu'elle soit standart .
Et c'est d'ailleur ce qui m'a permis de l'utiliser sur des projets asp mvc avec reel succes !
En cherchant un peu, je me rends compte que c'est... faux. L'apport principal de TypeScript, comme son nom l'indique, c'est le typage statique optionnel. Et ce n'est pas du tout à l'ordre du jour dans EcmaScript 6 :

http://wiki.ecmascript.org/doku.php?...armony:harmony
2  0 
Traroth2
Avatar de Traroth2
Membre émérite https://www.developpez.com
Le 22/10/2013 à 15:18
Citation Envoyé par elmcherqui Voir le message
Pourtant :
il c'est clairement cité ici :
http://en.wikipedia.org/wiki/TypeScr...ript_6_support

et ici :
http://en.wikipedia.org/wiki/ECMAScript

et ici :
http://en.wikipedia.org/wiki/TypeScript

En tous cas si je me trompe , merci pour la rectification
Ca veut juste dire que TypeScript contient des fonctionnalités d'EcmaScript 6, pas que c'est EcmaScript 6.

Citation Envoyé par elmcherqui Voir le message

Typescript n'est pas un nouveau langage destiné a corriger les defaut de javascript , mais tous simplement la version Ecmascript 6 de javascript
Non.
2  0 
Frédéric Latour
Avatar de Frédéric Latour
Membre actif https://www.developpez.com
Le 25/10/2013 à 16:28
Citation Envoyé par Traroth2 Voir le message
Si tu fais allusion à Node.js, les performances n'ont rien à voir avec l'utilisation de Javascript. C'est l'utilisation d'un thread unique et d'entrées-sorties non-bloquantes qui expliquent les performances. Il faut comparer ce qui est comparable, et si tu compares Node.js à des outils similaires écrits dans d'autres langages, comme Vert.x en Java, ça rigole déjà beaucoup moins :

http://www.cubrid.org/blog/dev-platf...n-with-nodejs/

Vert.x, pour ceux qui ne connaissent pas :

http://vertx.io/
En complément de ma remarque précédente concernant les performances du moteur javascript, le benchmark proposé est contesté à juste titre:

  • Les différences de performances pour l'un des tests sont le résultat du fait que node.js utilise un appel qui fera que le fichier ne sera jamais mis en cache et donc lu à chaque fois contrairement à la version vert.x. L'auteur du Benchmark se défend de ne pas être responsable de la manière dont le "caching" est effectué et que cela souligne une faiblesse de node.js.
    Certainement mais comme expliqué par "posteurs", quelqu'un un tant soit peu intéressé par les performances de son application ne laisserait pas node.js retourner des fichiers statiques sans mécanisme de cache s'il désire servir des centaines d'utilisateurs.
  • Pour l'autre test (qui n'implique pas de fichiers), il est impossible de limiter complètement vert.x à un seul core. Ainsi il est difficile de comparer si l'on ne tourne pas sur une machine/vm avec un seul core car vert.x utilisera automatiquement les ressources à sa disposition. Des tests on d'ailleurs été refaits et semblent indiquer que node.js offre de meilleurs performances par core.
  • Les tests sont réalisés avec seulement 60 connexions simultanées ce qui n'est pas suffisant si l'on considère les problématiques de "scaling" de la jvm.
  • Pas d'information sur la mémoire et l'utilisation CPU... ce qui est fondamental dans un contexte CLOUD ou la mémoire à un coût non négligeable.


Certains contradicteurs ont d'ailleurs refait le benchmark en cachant le fichier statique (car le test ne sert qu'un seul fichier) au démarrage (pour les 2 fx vert.x et node.js) montrant que node.js était nettement plus rapide (https://gist.github.com/courtneycouch/2652991). Ce test semble beaucoup plus significatif de la capacité du Framework à servir des données sans dépendre d'éléments externe.

D'une manière générale, bien que n'ayant aucun intérêt particulier avec node.js, ni rien contre vert.x, je trouve l'auteur des tests de mauvaise foi, et beaucoup moins convainquant que ses contradicteurs.

Quelques liens complémentaires qui permettront également de lire les contradicteurs:

http://vertxproject.wordpress.com/2012/05/09/vert-x-vs-node-js-simple-http-benchmarks/

https://news.ycombinator.com/item?id=3948727
3  1 
Frédéric Latour
Avatar de Frédéric Latour
Membre actif https://www.developpez.com
Le 29/10/2013 à 12:36
Citation Envoyé par Traroth2 Voir le message
Pas un seul article n'arrive à la conclusion que Node.js est plus performant que Vert.x :

https://www.google.fr/#q=benchmark+node.js+vert.x

Bon, je reconnais que je ne suis pas allé plus loin que la deuxième page...
Ce n'est quand même pas très difficile. Il suffit de suivre le premier lien qui apparaît dans mon message (https://gist.github.com/courtneycouch/2652991).

Dans ce Gist, le développeur a légèrement modifié le programme du benchmark initial afin de cacher le fichier qui est délivré lors d'une requête. En exécutant cette version modifiée sur une small instance m1 EC1. Les résultats montrent:
  1. l'exécution du progtramme en utilisant vert.x ne montre pas d'amélioration de performances ce qui montre que, même sans cacher, le fichier, il y a un mécanisme de caching (under the Hood) qui faussait les résultats.
  2. Nodes.js est 50% plus rapide dans le cadre de ce test.


Il est intéressant de lire ensuite les commentaires (du Gist) où, à mon avis, celui qui a réalisé les tests n'est pas particulièrement de bonne foi (chacun pourra se faire son avis).

Le contradicteur a également pris la peine de monter un test en environnemnet multicore: https://gist.github.com/courtneycouch/2657432
où là encore, nodejs est à son avantage.

Vert.x est certainement très intéressant et a des atouts spécifiques mais la polémique s'appuyant sur un test maladroit où l'auteur s'est, selon moi, enfoncé dans des arguments vaseux plutôt que de reconnaître son erreur n'est pas une très bonne chose pour la crédibilité du Framework (l'auteur du bench/blog semble faire partie de l'équipe de développement de vert.x).

J'espère que vous avez maintenant les informations suffisantes pour mieux juger et que, si vous désirez me contredire, ou plus généralement tenir votre position initiale, vous le ferez avec des arguments ... hummm ... disons un peu plus consistants.
3  1 
anthyme
Avatar de anthyme
Membre éprouvé https://www.developpez.com
Le 04/04/2014 à 17:11
@jojosbiz
Sauf que Typescript propose une solution aujourd'hui compatible avec l’intégralité du code js existant là ou dart est un monde a part et doit faire des connecteurs lourds à maintenir.

Je l'utilise sur 2 projets réel depuis les previews et le gain en solidité de code notamment vis a vis des refactoring est vraiment appréciable.
Ensuite vous pouvez avoir du javascript pur très solide aussi ... S'il est fortement couvert par des tests unitaires, et c'est encore rarement le cas sur les personne faisant pas mal de javascript.

Personnellement je ne mets pas des classes dans tous les sens, j'aime aussi la flexibilité de la programmation fonctionnelle de Javascript et de ses nested function.
Par contre pour ce qui est de la découverte des types dans l'IDE, la protection des erreurs à la compilation, les modules, les lambda, les interfaces c'est le top.
2  0 
Commenter Signaler un problème