Discussion :

[yahiko]

Panorama de l'écosystème TypeScript

Le langage TypeScript a désormais plus de deux ans et a atteint le stade de la production. Il continue cependant d'évoluer conformément à sa feuille de route avec une version 1.5 qui devrait être publiée d'ici quelques semaines.

Il peut donc être utile de faire le point sur l'adoption de ce langage parmi la communauté des développeurs.

Tendances de recherche

Evolution des tendances de recherche Google de janvier 2012 à mars 2015

source

Légende

• bleu : TypeScript
• rouge : Dart
• orange : CoffeeScript
• vert : Traceur
• violet : BabelJS

Le récent pic sur TypeScript s'explique autour du buzz causé par l'adoption de TypeScript par l'équipe d'Angular pour la version 2.0 de son fameux framework. Néanmoins, même en faisant abstraction de ce pic, on constate une progression solide de TypeScript. La tendance TypeScript dépasse celle de CoffeeScript. Ce dernier tout comme Dart stagne. Et le seul concurrent qui semble suivre la même évolution que TypeScript est le transpileur Traceur. Il est d'ailleurs intéressant de noter que les articles des sites spécialisés ont désormais tendance à comparer davantage TypeScript à Traceur ou à BabelJS plutôt qu'avec CoffeeScript ou Dart comme c'était le cas auparavant.


Créations de dépôts sur GitHub

Évolution annuelle* des créations de dépôts sur GitHub

source : Google Big Query

* Chaque période annuelle s'étend de mars à février

L'année 2013-2014 a vu TypeScript dépasser Dart en nombre de dépôts GitHub avec une progression fulgurante de ce premier (+629%). Sur l'année 2014-2015, TypeScript est redescendu à des niveaux de création plus raisonnable (+11%), l'effet de découverte s'étant tassé. Il se paye quand même le luxe de dépasser la croissance de JavaScript lui-même (+4%). C'est un indicateur significatif.
Le langage CoffeeScript reste populaire avec un nombre important de créations de dépôts, mais sa croissance est en stagnation (+0%). Sans doute le signe avant-coureur d'un lent déclin, faute de soutien de taille.
Enfin, le langage Dart de façon surprenante voit le nombre de créations de dépôts régresser, et de façon importante (-26%). Ce n'est pas anodin et est sans doute le signe que le langage de Google ne parviendra sans doute pas à percer à terme.


Classement de popularité RedMonk

Premier trimestre 2015

Ce classement confirme les chiffres précédents sur l'axe GitHub. On note que TypeScript reste encore derrière Dart pour ce qui est des questions posées sur les forums. Toujours est-il que TypeScript consolide sa place dans le quart supérieur droit (leader quadrant) de ce classement.


Editeurs / EDI supportant / pouvant supporter TypeScript

• Visual Studio : Support natif de TypeScript
• WebStorm : Support natif de TypeScript
• Sublime Text : Better TypeScript
• Atom : Plugin TypeScript
• Eclipse : TypEcs
• Emacs : Coloration syntaxique TypeScript
• Vim : Plugin TypeScript

Projets utilisant / supportant TypeScript

• Microsoft Azure : 1,5 million de lignes de code en TypeScript
• Telerik : Son framework Native Script est codé en TypeScript
• Asana : Migration de sa base de code en TypeScript
• BabylonJS : Framework WebGL porté en TypeScript
• Angular 2.0 : Framework applicatif qui supportera nativement TypeScript
• Meteor : Framework applicatif supportant officiellement TypeScript
• Aurelia : Framework applicatif supportant officiellement TypeScript
• Phaser : Framework de jeux supportant TypeScript

Enfin, le projet DefinitelyTyped qui s'est donné pour objectif de simplifier l'importation de bibliothèques JavaScript existantes en fournissant des fichiers de définition TypeScript *.d.ts ne cesse de s'enrichir chaque jour. La bibliothèque jQuery est évidemment supportée, mais aussi Angular 1, ReactJS, Ember, NodeJS, Backbone, MongoDB, etc.


Et vous ?
TypeScript pourra-t-il devenir un langage majeur ?
Pensez-vous essayer TypeScript ?

[Vlozer]

Personnellement, à l'utilisation je trouve Dart bien plus agreable (syntaxe plus lisible et banale, gestionaire de library embarqué, ide officiel dédié et multiplateforme, bilbiotheque du langages tres riches que ce soit dans la manipulation du DOM/Gestion de Thread/ect)... Donc meme dans l'hypothese où la DartVM ne soit jamais supportée par aucun navigateur, ça reste un choix qui me convient.

En tout cas d'ici à ce qu'ils trouvent un vrai successeur à javascript (d'ici une centaine d'année à ce rythme)...

[yahiko]

En tout cas d'ici à ce qu'ils trouvent un vrai successeur à javascript (d'ici une centaine d'année à ce rythme)...

Tout peut aller très vite. TypeScript reste pour le moment un langage confidentiel, tout comme Dart.
Mais à partir du moment où il sera adopté par des gros projets/grosses entreprises prescriptrices, l'adoption peut être exponentielle.

De plus de nombreux projets Github écrits en TypeScript sont injustement rangés dans la catégorie JavaScript dans le cas fréquent où le source JavaScript est joint au source TypeScript. C'est le cas de la totalité de mes projets TypeScript sur GitHub qui sont pourtant étiquetés en projets JavaScript.

Pour Dart en lui-même, si ce n'est sa génération en JS que je trouve trop différente du code de départ, je n'ai aucun problème avec le langage en lui-même.
Maintenant son talon d'Achille est l'absence d'interopérabilité avec les frameworks ou bibliothèques JavaScript ce qui limite les possibilités dès qu'on veut faire des choses sérieuses.

[xulien]

Il se paye quand même le luxe de dépasser la croissance de JavaScript lui-même (+4%). C'est un indicateur significatif.

Mouahahaha! significatif de quoi au juste!?

creation sur la période en javascript : 22925 projets
creation sur la période en typescript : 568 projets soit 2.48% du nombre de projets créer en javascript sur la période...

"Si ma tante en avait on l'appellerait mon oncle"
Pierre Dac

[yahiko]

Je me doutais bien qu'il y aurait bien quelqu'un qui ne comprendrait pas la notion de croissance du nombre de créations.

Ton "calcul" correspond en fait à la création de la création (ou la dérivée seconde si tu préfères). Mais ça te dépasse déjà peut-être ^^

Quand le sage montre la Lune, l'idiot ne voit que le doigt

[xulien]

Je me doutais bien qu'il y aurait bien quelqu'un qui ne comprendrait pas

bha si justement

la notion de croissance du nombre de créations

je comprends bien qu'il n'y a rien à comprendre...

Mais ça te dépasse déjà peut-être ^^

tu n'es pas obligé d'être méchant et en partant du principe que je suis un c**

D'autant que tu n'expliques pas plus en quoi c'est significatif de quoi que ce soit.

avec une telle différence de volume cela n'a aucun sens.

Prenons un exemple que même les simplets comme moi peuvent appréhender (en plus quand on parle de brouzouf, tout le monde comprends) :

x gagne 135600€ par mois, on l'augmente de 4%, soit 5400€
y gagne 1100€ par mois, on l'augmente de 11%, soit 121€

"le smic se paye quand même le luxe de dépasser la croissance du salaire des patrons d'entreprises du cac40 lui-même (+4%). C'est un indicateur significatif."

L'absurdité de l'indicateur te saute-t-elle plus facilement au yeux?

[yahiko]

tu n'es pas obligé d'être méchant et en partant du principe que je suis un c**

J'espère que tu n'as pas pleuré mon petit chou
Disons que c'était la réponse du berger à la bergère si tu vois ce que je veux dire.

D'autant que tu n'expliques pas plus en quoi c'est significatif de quoi que ce soit.

avec une telle différence de volume cela n'a aucun sens.

Prenons un exemple que même les simplets comme moi peuvent appréhender (en plus quand on parle de brouzouf, tout le monde comprends) :

x gagne 135600€ par mois, on l'augmente de 4%, soit 5400€
y gagne 1100€ par mois, on l'augmente de 11%, soit 121€

"le smic se paye quand même le luxe de dépasser la croissance du salaire des patrons d'entreprises du cac40 lui-même (+4%). C'est un indicateur significatif."

L'absurdité de l'indicateur te saute-t-elle plus facilement au yeux?

Une différence de progression reste une différence de progression.
Les volumes de TypeScript étant significatifs (plusieurs milliers de créations par an, donc on suppose que la loi des grands nombres s'applique), cela n'est pas gênant de les comparer avec ceux de JavaScript qui a une croissance moindre et qui a vraisemblablement atteint un stade de maturité sur GitHub ou en tout cas s'en approche.

D'autant plus que comme je l'ai fait remarquer, les créations de dépôt TypeScript sont probablement sous-estimés à cause du système de classification de GitHub qui tend à assimiler les projets TypeScript aux projets JavaScript.

EDIT : Et concernant ton exemple du salaire, il est à côté de la plaque. Désolé encore une fois si cela te vexe.
Comparaison n'est pas raison.
Tu veux comparer un phénomène statistique, celui de la création de dépôts/projets par des milliers d'utilisateurs autonomes, avec le résultat d'un négociation/rapport de force entre deux agents économiques. Cette négociation/rapport de force n'ayant que peu de chose à fois avec la statistique des grands nombres.

[xulien]

Disons que c'était la réponse du berger à la bergère si tu vois ce que je veux dire.

bha non, pas vraiment... mon rire gras portait sur un propos bien précis de ton article, pas sur ta personne...

Une différence de progression reste une différence de progression.

euh... oui, effectivement, et ce n'est d'ailleurs pas mon propos, car tu peux mesurer la différence de progression de la croissance du champignon de Paris en sole argileux avec l'augmentation du nombre de supporter du PSG sur une période données, c'est aussi une différence de progression, mais cela n'en fait pas plus un indicateur pertinent et significatif de quoi que ce soit.

Les volumes de TypeScript étant significatifs

ah... par rapport à quoi? parceque c'est si le nombre de projets typescript créer sur la période par rapport au nombre de creation de projet en javascript , cela représente moins de 1%...

D'autant plus que comme je l'ai fait remarquer, les créations de dépôt TypeScript sont probablement sous-estimés à cause du système de classification de GitHub

de plus tu admets toi même que t'es données ne sont pas fiables ou représentatives.

donc on suppose que la loi des grands nombres s'applique

Que vient faire la loi des grands nombres là dedans?!
pour rappel: "En statistiques, la loi des grands nombres exprime le fait que les caractéristiques d'un échantillon aléatoire se rapprochent d'autant plus des caractéristiques statistiques de la population que la taille de l'échantillon augmente"


Mais qu'il n'y ai pas de malentendu, je n'avais nullement l'envie de pourrir les commentaires en coupant les cheveux en quatre; simplement faire remarquer que la "notion de croissance du nombre de créations" n'est en rien indicateur d'une quelconque tendance, car il y a bcp (mais bcp bcp) plus de projets en javascript qu'en typescript, et qu'il y a encore bcp (mais bcp bcp) plus de nouveau projets en javascript qu'en typescript... en terme de popularité, car il s'agit bien de ca en fait, mesurer la croissance de popularité de typescript par rapport à javascript (et consort), bha, quelques soit les raisons (sujet plus intéressant à mon sens d'ailleurs), la popularité de typescript sur javascript en ce basant sur les données de github, c'est "peau de zob". pas besoin de faire appel à la loi des grands nombres pour s'en rendre compte

[Paleo]

De plus de nombreux projets Github écrits en TypeScript sont injustement rangés dans la catégorie JavaScript dans le cas fréquent où le source JavaScript est joint au source TypeScript. C'est le cas de la totalité de mes projets TypeScript sur GitHub qui sont pourtant étiquetés en projets JavaScript.

À mon avis, il ne faudrait pas. On ne met pas les fichiers compilés sur les dépôts de projets en C++ ou en Java, pourquoi faudrait-il le faire en TypeScript ? Les fichiers à télécharger associés aux releases servent à cela.

creation sur la période en javascript : 22925 projets
creation sur la période en typescript : 568 projets soit 2.48% du nombre de projets créer en javascript sur la période...

Si l'on veut parler de "croissance du nombre de créations" il faut dans ce cas rester sur le même produit.

Oui.

Il est encore un peu tôt pour se réjouir des statistiques.

TypeScript est bien pensé. C'est un produit simple, techniquement solide, il a pris une place que les équipes de Google n'avaient pas vue. L'annonce de l'adoption par Angular 2 est la toute première publicité que le langage reçoit, en effet, Microsoft n'a jamais vraiment communiqué sur son langage. Pourtant l'architecte de TypeScript est Anders Hejlsberg, pourtant JavaScript est un langage natif pour Windows, et pourtant la VM JavaScript de Microsoft est plutôt bien placée dans la course à l'implémentation de EcmaScript 6.

Que penser de tout ceci ? Je crois que Microsoft a pris son temps pour faire du costaud et choisir les bonnes options. Par exemple, en octobre dernier, Microsoft a publié la version 1.1 qui était une réécriture complète du compilateur sans ajout de fonctionnalités. Pourquoi réécrire le compilateur d'un langage presque inconnu qui n'avait que deux ans ? Sur la feuille de route, regardez le nombre de fonctionnalités du langage et le rapprochement avec ES6. Nous en sommes à la version 1.4. Le nombre des fonctionnalités implémentées en si peu de temps est juste sidérant. TypeScript est en train de sortir de sa boite.

Traceur n'a aucun avenir pour la production puisque, comme Dart, c'est une solution complexe et fermée, il suffit d'essayer son REPL pour s'en convaincre. Il existait avant TypeScript sans que personne n'en entende parler. Il est sorti de l'oubli en 2014 lorsque l'équipe de Angular 2 avait annoncé vouloir l'utiliser, mais puisque c'est terminé, bye bye Traceur.

CoffeeScript restera un challenger de bonne réputation.

Babel est un outil temporaire : au fur et à mesure de l'implémentation de ES6 par les navigateurs, il pourra être délaissé. Il fait en outre double emploi avec TypeScript. Plus TS se rapproche de ES6 et plus les deux transpilers marchent dans les mêmes plates-bandes.

[Greg-dev]

Je ne pense pas que Typescript deviendra un langage majeur, Javascript restera la référence côté navigateur.
D'ailleurs je me demande combien de temps Microsoft et Google vont perdre leur temps avec leurs "sur-ensemble".

[deltree]

C'est quand même angular qui tire Javascript actuellement amha ( au moins là ou je travaille ). Il semble naturel pour ceux qui travaillent avec Angular d'utiliser TypeScript si c'est l'avenir d'angular. En plus le langage n'est pas usine à gaz, je le trouve facile à écrire (contrairement à CoffeeScript).

[zulu1]

En fait, la guerre se fera tant que javascript ne redeviendra pas livescript, comme à son origine. Peut-être Harmony changera la donne.

[Paleo]

Voici un article qui va dans le sens de celui de yahiko.

J'aime bien le parallèle avec SASS.

[yahiko]

Le framework applicatif haute performance Bobril, qui s'inspire pour une large partie de ReactJS dans ses fonctionnalités, vient d'atteindre la version 2.0.0.

Il en profite pour un lifting puisqu'il a été entièrement converti en TypeScript 1.5, alors que cette dernière version du langage n'est qu'au stade alpha.

Dépôt Github

[yahiko]

La société Wix qui propose des solutions pour la création de sites internet vient de partager un retour d'expérience très intéressant sur TypeScript au sein de sa solution eCommerce WixStores.

L'auteur explique en quoi les problématiques du JavaScript de base ont poussé sa société à essayer TypeScript. Les problèmes de fiabilité du code JavaScript écrit à la main deviennent trop importants à mesure que la base de code grandit. Sur des applications de grande ampleur, le typage statique devient indispensable.

Parmi les quelques regrets qui existe selon lui au niveau de TypeScript, ils sont principalement liés à une diffusion encore restreinte du langage, avec un support parfois partiels des éditeurs et EDI du langage TypeScript, et une base de connaissance sur Internet via des sites comme StackOverflow assez limitée pour le moment.

Blog officiel TypeScript

[yahiko]

Les utilisateurs de l'éditeur de texte Vim (enfin, s'il en reste !) auront le plaisir de savoir qu'un plugin du nom de Tsuquyomi vient d'être publié sous sa version 0.3.1.

En plus d'apporter la coloration syntaxique (ce qui est le minimum), ce plugin utilise l'API du compilateur TypeScript (Language Services) et permet entre autre l'auto-complétion et la recherche des références basées sur le typage.

Dépôt GitHub

[yahiko]

Babel supporte officiellement TypeScript

Babel, emblématique transpileur JavaScript anciennement dénommé es6to5, supporte désormais la syntaxe TypeScript via un premier plugin sous la forme d'un parseur (analyseur syntaxique). Cette nouvelle fonctionnalité est disponible avec la version 7.0.0-beta.16.

Même si c'est pour le moment un peu limité comme fonctionnalité, il faudra par exemple attendre d'avoir un plugin plus complet pour valider et transpiler intégralement du code TypeScript en du code JavaScript, cela montre sans doute un intérêt croissant de la communauté des développeurs Web envers le langage de Microsoft.

source : dépôt GitHub de Babel

Pensez-vous que l'intégration de TypeScript dans Babel soit intéressante ?
Cela pourra-t-il vous inciter à vous pencher sur TypeScript ?

[yahiko]

Reddit choisit TypeScript pour leur frontend

Le célèbre site communautaire reddit vient d'annoncer qu'il avait choisit le langage TypeScript, surensemble typé de JavaScript, pour la réécriture de leur site.
L'auteur de l'article, Niranjan Ramadas, Engineering Manager, présente les différents critères qui ont amené l'entreprise à choisir ce langage plutôt qu'un autre :

• Le typage ;
• L'outillage ;
• L'utilisation dans des applications de grande ampleur ;
• La facilité d'apprentissage pour l'équipe en place ;
• La capacité à opérer côté serveur et client ;
• L’interopérabilité avec les bibliothèques existantes.

On apprend que le débat s'est porté principalement entre JavaScript+Flow d'un côté, et TypeScript de l'autre avec une évaluation sur trois axes :

1. La compilation vs. l'annotation ;
2. La consistance du système de typage (soundness) ;
3. L'écosystème.

Concernant les différences entre la compilation et l'annotation, l'auteur de l'article indique que l'annotation, l'approche de Flow, a pour avantage de ne pas trop complexifier la chaîne de développement, à contrario de TypeScript (ndr: même si c'est loin d'être insurmontable). En revanche, l'auteur montre que la compilation a pour avantage d'écrire les types de façon plus naturelle, moins verbeuse, que son équivalent en annotation où il faut en plus coder en JavaScript l'implémentation des types. L'exemple d'une énumération montre bien ce phénomène.

Concernant la détection éventuelle d'erreur dans le typage, l'auteur a une préférence pour Flow qu'il estime plus pointu dans ce domaine. En effet, TypeScript a historiquement privilégie la correction syntaxique du typage (pour des raisons de facilité d'implémentation et de compatibilité avec JavaScript) avant la consistance, là où Flow a été principalement développé en ce sens. C'était vrai encore il y a quelques mois, mais depuis les versions les plus récentes de TypeScript et notamment la 2.4 où la contravariance sur les types génériques a été introduite, le jugement de l'auteur pourrait être amené à évoluer.

Enfin, le dernier axe d'évaluation, la richesse de l'écosystème, l'auteur indique que TypeScript bénéficie d'un net avantage sur Flow grâce à une vaste collection de typages sur les bibliothèques JavaScript les plus courantes, grâce à un grand support du langage dans les outils de développement, notamment l'Intellisense qui se retrouve dans nombre d'éditeurs, grâce à la capacité de TypeScript à comprendre les commentaires à la JSDoc pour en inférer le type sur des projets JavaScript existants, et grâce aux garanties "sociales" de TypeScript dans la mesure où le langage a été adopté dans nombre de projets de grande ampleur, notamment Angular. L'inquiétude de l'auteur envers Flow est que celui-ci a été développé plus spécifiquement pour les besoins de Facebook (ndr : et notamment React), alors que TypeScript a d'emblée eu une vocation généraliste. En aparté, l'auteur estime que puisque TypeScript se veut comme un surensemble de JavaScript, il y a une certaine garantie que la part de Microsoft que le langage suive les évolutions de la norme ECMAScript en faisant évoluer son système de typage en conséquence.

Pour conclure sur les mots de l'auteur :

Nous avons choisi TypeScript parce que nous sommes confiant dans le fait que les devs puissent l'appréhender rapidement (le nombre d'ingénieur frontend a triplé en un an), que le langage peut accomplir nos objectifs sur la refonte complète du site,
qu'il soit pérenne pendant un moment, et qu'il puisse être interopérable avec notre base de code existante. Mais plus important, nous avons basculé vers un langage qui est typé. Utiliser un langage typé pour notre frontend a déjà été payant : notre code a moins de bugs liés au typage, nous sommes plus confiants lors des grands remaniements de code, et notre documentation au sein du code est davantage orientée sur les concepts que sur la structure des objets et des paramètres de fonctions. Globalement, nous sommes très contents de notre choix.

.
source : Blog officiel de Reddit

Que pensez-vous de la décision de Reddit ?
Existe-t-il une réflexion similaire dans votre entreprise ?

[Benjamin Gates]

Ne soyez pas si excitE, ce n'est qu'une periode de test pour millions de developpeurs web avant de finalement prendre leur position par rapport au nouveau langage...