Microsoft propose TypeScript pour le développement de projets JavaScript

Microsoft propose TypeScript pour le développement de projets JavaScript

Ceci n'est pas un concurrent de Dart

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

02/10/2012 4 minutes
32

Microsoft propose TypeScript pour le développement de projets JavaScript

Depuis deux ans environ, Microsoft embrasse largement les technologies du web. Cela comprend notamment le JavaScript au point d’avoir fait de ce langage un des rouages de sa plateforme WinRT pour la construction des applications Windows 8. Aujourd’hui, Microsoft propose la préversion d’un langage destiné à mieux gérer les gros projets en JavaScript.

 

Un « superset » du JavaScript

Il se nomme TypeScript et se destine donc aux développeurs travaillant sur de vastes projets en JavaScript. Ce dernier, bien que populaire, n’a pas été conçu pour l’utilisation dont il fait l’objet aujourd’hui. Or, le JavaScript est de plus en plus utilisé justement, dans des projets dont la taille augmente. Chez Microsoft par exemple, il est l’un des langages utilisables pour la construction des applications WinRT (Modern UI, ex-Metro), ce qui booste encore son attractivité : le JavaScript est devenu un langage à tout faire.

 

typscript

 

Dans le billet explicatif sur TypeScript, Soma Somasegar, vice-président de la division Developer, indique que la proposition de Microsoft est conçue pour répondre à des besoins spécifiques. TypeScript n’a pas pour vocation de remplacer le JavaScript, mais de lui apporter une syntaxe et des outils particuliers. Il est un « superset » du JavaScript dont il reprend une grande partie de la syntaxe. Pour information, le projet a été initié par Anders Hejlsberg, père du C#, Steve Lucco, créateur de la machine virtuelle JavaScript Chakra et Luke Hoban, un expert en langages qui travaille essentiellement sur le standard ECMAScript.

Travailler en JavaScript sur de gros projets

Le grand objectif de TypeScript est d’aider les développeurs à construire de grands projets, aussi bien du côté client que du côté serveur, en prenant en compte les équipes. Microsoft veut en effet apporter au JavaScript les avantages d’un langage typé, d’où d’ailleurs le nom de leur projet : TypeScript.

 

Comme l’indique Soma Somasegar, tout code JavaScript est un code TypeScript. Ce dernier reste basé sur le standard ECMAScript et tous les frameworks utilisés pour JavaScript sont également compatibles : Node.js, jQuery, ou encore Underscore.js. Sur l’ensemble, TypeScript ajoute des types statiques optionnels, des classes et des modules (alignés avec ceux du standard ECMAScript 6 en formation). En bout de ligne, le code JavaScript produit après la compilation est classique et peut s’exécuter n’importe où.

Une plateforme open source 

Pour autant, Microsoft ne réinvente pas la roue. Le projet est très différent d’initiatives concurrentes telles que Dart de Google puisque le langage utilisé reste le JavaScript. Même su la syntaxe peut changer, la compilation se fait toujours en JavaScript à la fin. En outre, l’ensemble du projet est placé sous licence Apache 2.0 et le code source du compilateur sur le site officiel du TypeScript.

 

Il n’y a évidemment pas de hasard : Microsoft travaille sur TypeScript car ce langage pourrait aider les développeurs dans des projets conçus pour les produits de la firme. La préversion peut déjà être exploitée sous la forme d’un plug-in pour Visual Studio ou d’un paquet NPM (Node Package Manager). Les développeurs pourront donc s’en servir aussi bien pour créer des applications WinRT que des projets côté serveur avec Windows Azure.

 

Il ne s’agit pour l’instant que d’une préversion du langage et donc du compilateur. Le projet va s’affiner dans les prochains mois et les développeurs sont invités à donner leur avis. Reste à voir finalement si TypeScrit prendra, mais il se pourrait finalement que les développeurs s’y intéressent à cause de son orientation : apporter des outils pour répondre à des situations particulières sans remplacer l’existant.

 

Ceux qui souhaitent en savoir davantage pourront se rendre sur le site officiel du projet.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

 

Fermer

Commentaires (32)


<img data-src=" /> Tiens, un projet de MS qui pourrait m’intéresser. C’est vrai que pour des trucs complexe, la syntaxe du Js est parfois pas simple… enfin surtout les scopes qui m’emmerde plus que le reste.


C’est pas mal sachant que le javascript est accélérer de façon matériel sur les dernières version des navigateurs <img data-src=" />




Le projet est très différent d’initiatives concurrentes telles que Dart de Google puisque le langage utilisé reste le JavaScript.



Le Dart peut aussi être compilé vers le JavaScript… Comme plus généralement tous les projets d’amélioration de ce dernier.








newsmars a écrit :



C’est pas mal sachant que le javascript est accélérer de façon matériel sur les dernières version des navigateurs <img data-src=" />





C’est pas JavaScript qui est accéléré matériellement, c’est le rendu graphique.

Ce que les navigateurs ont rajouté, c’est un pré-compilateur qui compile le javascript en pseudo-code, mais pas directement du code machine.



Projet intéressant.<img data-src=" />


ça a l’air pas mal tout ça….


Du javascript côté serveur, y a vraiment des gens malades pour inventer/promouvoir cette horreur…


Humm pourquoi pas mais au final, même si c’est codé en JS, le résultat n’est pas très différent de Dart. Faudrait comparer la qualité des codes JS générés…


C’est pas mal du tout le javascript est quand même une plaie pour les gros développements quand on a touché à d’autres langages. Je me souviens de propos de certains développeurs chez Microsoft qui expliquait que le javascript pourrait devenir l’assembleur du web. Sur le principe c’est exactement ça.








kochka22 a écrit :



Humm pourquoi pas mais au final, même si c’est codé en JS, le résultat n’est pas très différent de Dart. Faudrait comparer la qualité des codes JS générés…





Le code résultant n’est pas très important. L’intérêt c’est surtout d’éviter de coder en javascript et d’utiliser un vrai langage typé.









hadoken a écrit :



Du javascript côté serveur, y a vraiment des gens malades pour inventer/promouvoir cette horreur…





Il existe même du css coté serveur.Je conseille c’est pas mal du tout



earth01&gt;Non, c’est bien du code x86 en sortie des moteurs JS des navigateurs. A ma connaissance, y a que V8 qui a pour projet de faire cracher du bytecode à V8.



En fait, c’est juste une implémentation d’ES6 par Microsoft <img data-src=" />








charon.G a écrit :



Le code résultant n’est pas très important. L’intérêt c’est surtout d’éviter de coder en javascript et d’utiliser un vrai langage typé.







Je ne parlais pas de lisibilité mais de performances.









kochka22 a écrit :



Je ne parlais pas de lisibilité mais de performances.





Les performances oui <img data-src=" />









charon.G a écrit :



Il existe même du css coté serveur.Je conseille c’est pas mal du tout





Avec l’arrivé des variables dans le CSS, ça va un peu diminuer l’intérêt de ce genre de langage. Et j’ai du mal à comprendre comment certaines règles des sélecteurs de niveau 4 sont applicable avec.









zefling a écrit :



Avec l’arrivé des variables dans le CSS, ça va un peu diminuer l’intérêt de ce genre de langage. Et j’ai du mal à comprendre comment certaines règles des sélecteurs de niveau 4 sont applicable avec.





CSS4 ne sera pas diffusé massivement tout de suite, donc ce genre de langages devrait perdurer encore un peu.



Je ne vois pas vraiment la différence avec Dart, excepté que dans certaines conditions Dart peut-être exécuté directement…


La différence entre typescript et dart c’est que typescript est bien plus proche de javascript et donc interopérable et moins de surcouches.



Hello World en typescript fait 1 ligne de code de JS en dart c’est plus de 17000 lignes …



C’est carrément plus light








anthyme a écrit :



La différence entre typescript et dart c’est que typescript est bien plus proche de javascript et donc interopérable et moins de surcouches.



Hello World en typescript fait 1 ligne de code de JS en dart c’est plus de 17000 lignes …



C’est carrément plus light





Tu connais pas l’émoticone comme langage ? c’est encore plus simple: <img data-src=" />



Je parle de légèreté du code généré mais aussi ET surtout d’exécution,



En dart on a la VM JS du navigateur plsu uen VM Dart qui tourne ici on a uniquement la VM Javascript.



Sans parler de l’intérop native avec toutes les lib Javascript.

Tu essais Dart et tu vois le gouffre de perte que tu as par rapport à coder en Javascript à cause des milliers de lib qui manquent.








Crysalide a écrit :



Tu connais pas l’émoticone comme langage ? c’est encore plus simple: <img data-src=" />





Le problème du premier compilateur c’est qu’il ramenait toutes les libs en JS même pour une ligne de code. Je ne sais pas si c’est toujours le cas.



Enfin on fait bien la même chose avec Jquery UI pour faire 2 pauvres effets sur un site qui pendait même pas 5 Ko à coder en JS.









anthyme a écrit :



Je parle de légèreté du code généré mais aussi ET surtout d’exécution,



En dart on a la VM JS du navigateur plsu uen VM Dart qui tourne ici on a uniquement la VM Javascript.



Sans parler de l’intérop native avec toutes les lib Javascript.

Tu essais Dart et tu vois le gouffre de perte que tu as par rapport à coder en Javascript à cause des milliers de lib qui manquent.





Si tu avais lu l’article tu aurais vu que ça n’a aucune intention de remplacer javascript, mais de la compléter, le remplacer sur les tâches qu’il sait faire, laisser la place à JS sur ce qu’il ne sait pas faire.










newsmars a écrit :



C’est pas mal sachant que le javascript est accélérer de façon matériel sur les dernières version des navigateurs <img data-src=" />





Rho la vache ! T’as une carte accélératrice JS dans ton PC toi ?





charon.G a écrit :



Il existe même du css coté serveur.Je conseille c’est pas mal du tout





Je préfère le SASS (http://sass-lang.com/ ), mais juste parcequ’il est plus répandu sur Rails.









zefling a écrit :



Avec l’arrivé des variables dans le CSS, ça va un peu diminuer l’intérêt de ce genre de langage. Et j’ai du mal à comprendre comment certaines règles des sélecteurs de niveau 4 sont applicable avec.





Faut avoir gouté aux frameworks avec pipeline statique pour voir l’intéret. Ruby on Rails &gt;= 3.1 est un parfait exemple =&gt;http://guides.rubyonrails.org/asset_pipeline.html



Avec SASS (génère du CSS), Haml (génère du HTML) et CoffeeScript (génère du Javascript), on sépare complètement le code qu’on écrit, le code exécuté par le serveur et le code exécuté par le client (et Rails intègre cet ecosystème tellement bien qu’on a même plus besoin d’y penser…ça se compile à la volée en environnement de dev, et c’est précompilé en prod).



Ecrire les choses comme on les pense et non plus comme le navigateur les accepte, c’est un aller sans retour.



TypeScript va totalement dans ce sens.









zefling a écrit :



Avec l’arrivé des variables dans le CSS, ça va un peu diminuer l’intérêt de ce genre de langage. Et j’ai du mal à comprendre comment certaines règles des sélecteurs de niveau 4 sont applicable avec.





Autant pouvoir faire des calculs pour la taille d’une balise par exemple, je dit pas ça à du sens. Mais des variables… Puis après le IF, le WHILE et la possibilité de déclarer des méthodes vont finir par suivre ? (Puis on diras, “mais c’est génial, si on rajoutais ce qui manque je peut faire une webapp juste avec du CSS !” <img data-src=" /> Tiens ça me rappelle quelque chose <img data-src=" />)



Déjà que le HTML en tant que langage décrivant des documents, s’en servir pour coder des applications entières c’était pas spécialement beau (un peu comme vouloir utiliser Word/Excel/Access/VB pour faire des applis), mais alors avec un langage décrivant la décoration d’un document…



Avec TypeScript, j’ai l’impression que chez Microsoft, on se dit : “Put* bon allez on accepte le JS dans WinRT pour recruter le réservoir de devs là-dessus, mais alors on arrange un peu le portrait de JS histoire que ça ressemble un minimum à un langage de programmation moderne et éviter d’engendrer des horreurs sans nom”. <img data-src=" />









Oungawak a écrit :



Autant pouvoir faire des calculs pour la taille d’une balise par exemple, je dit pas ça à du sens. Mais des variables… Puis après le IF, le WHILE et la possibilité de déclarer des méthodes vont finir par suivre ? (Puis on diras, “mais c’est génial, si on rajoutais ce qui manque je peut faire une webapp juste avec du CSS !” <img data-src=" /> Tiens ça me rappelle quelque chose <img data-src=" />)





Sauf que les variables CSS n’ont rien à voir avec celle de programmation. Tu leurs définis un domaine de validé avec le sélecteur. Ça éviter d’avoir à passer par un framework pour écrire 40 fois la même couleur. C’est plus proche d’une constante que d’une variable. D’ailleurs je pense que ça va être un truc assez compliquer à maitriser.



Un peu comme le sélecteur qui permet de définir le sujet d’action genre :

!div &gt; a:hover { border-color:red; }

qui permet de définir que la bordure devient rouge du div quand on survole le lien qui le continent. (Le sélecteur que j’attends le plus <img data-src=" />)









Oungawak a écrit :



Autant pouvoir faire des calculs pour la taille d’une balise par exemple, je dit pas ça à du sens. Mais des variables…





Quand tu as la même valeur (pixels, couleur, …) a appliquer à plusieurs éléments, en quoi c’est déconnant ?







Oungawak a écrit :



Puis après le IF, le WHILE et la possibilité de déclarer des méthodes vont finir par suivre ?





Heu….on peut déjà faire des “mixins” qui reviennent plus ou moins à des fonctions procédurales…Par contre il faut bien piger que tout ça n’est exécuté qu’à la compilation. A la fin on récupère du pu CSS.



Par contre ce dont je ne peux plus me passer en SASS, c’est l’imbrication :



SASS :

table.hl {

margin: 2em 0;

td.ln {



 text-align: right;   



}

}



li {

font: {



 family: serif;   

weight: bold;

size: 1.2em;



}

}



CSS :

table.hl {

margin: 2em 0;

}

table.hl td.ln {

text-align: right;

}



li {

font-family: serif;

font-weight: bold;

font-size: 1.2em;

}









porecreat a écrit :



Rho la vache ! T’as une carte accélératrice JS dans ton PC toi ?



Je préfère le SASS (http://sass-lang.com/ ), mais juste parce qu’il est plus répandu sur Rails.





J’ai choisi less car il existait une implémentation pour .NET









zefling a écrit :



Sauf que les variables CSS n’ont rien à voir avec celle de programmation. Tu leurs définis un domaine de validé avec le sélecteur. Ça éviter d’avoir à passer par un framework pour écrire 40 fois la même couleur. C’est plus proche d’une constante que d’une variable.





Ouf, là ça va alors. <img data-src=" />









charon.G a écrit :



J’ai choisi less car il existait une implémentation pour .NET





Je crois que c’est pas loin d’être kif kif ;o)









porecreat a écrit :



Je crois que c’est pas loin d’être kif kif ;o)





je crois aussi









porecreat a écrit :



Je crois que c’est pas loin d’être kif kif ;o)











charon.G a écrit :



je crois aussi







Du tout c’est très con d’avoir 2 trucs qui font la même chose.

On se retrouve avec https://github.com/thomas-mcdonald/bootstrap-sass qui converti Bootstrap de LESS vers SASS.