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 entre dans le top 15 des langages les plus populaires selon GitHub
Et figure aux côtés de Swift et de JavaScript

Le , par yahiko
79 commentaires

800PARTAGES

8  2 

Le célèbre hébergeur de codes source, GitHub, vient de publier un récapitulatif de son activité sur l'année 2015-2016.

Parmi différents faits et indicateurs, on peut y trouver un classement des quinze langages de programmation les plus populaires, classés par nombre de Pull Requests (PR) sur les douze derniers mois. L'idée étant de se baser sur la tendance (le flux) en privilégiant les dépôts et langages actifs, plutôt que les bases de code "mortes" et délaissées, mais qui seraient toujours comptabilisées dans un classement par nombre de dépôts (le stock).

A ce petit jeu, JavaScript caracole en tête sans contestation possible avec plus de 1,6 millions de PR. Java, second avec plus de 760 000 PR, se fait talonner par Python et Ruby, respectivement 3e et 4e. Les mauvaises langues y verront un signe du déclin, certes relatif, du langage d'Oracle.

Mais c'est surtout en bas de ce classement que ce situe les principales surprises. Swift, le langage d'Apple, et TypeScript, le langage de Microsoft, rentrent dans ce classement à la 14e et 15e place, soit un nombre de PR plus que triplé par rapport à l'année dernière.

TypeScript, surensemble typé de JavaScript, qui n'était qu'un langage tout à fait confidentiel il y a trois ans, a vu sa notoriété croitre sans cesse depuis, au point presque de devenir mainstream. Il reste encore bien des palliers à franchir avant d'arriver à ce stade de reconnaissance, mais la dynamique ininterrompue de JavaScript semble jouer en sa faveur.


source : GitHub

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

79 commentaires
Commenter Signaler un problème
SylvainPV
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 24/09/2016 à 1:01
Je pilote les devs d'un projet Angular 2 depuis le début de l'année avec une équipe de 4-5 personnes. Etant très méfiant vis à vis de l'avenir de TypeScript (par rapport à Dart, CoffeeScript et tous ses prédécesseurs enterrés), j'ai choisi de rester sur Babel avec quelques presets se rapprochant de la syntaxe TypeScript (types, annotations, décorateurs, propriétés de classes...). C'est une sorte d'intermédiaire entre Flow et TypeScript, qui me donnait une porte de sortie (au cas où) tout en pouvant utiliser la documentation TS pour Angular.

Mes collègues ont un meilleur niveau en Java qu'en JS à la base, ils ont donc bien accueilli les ressemblances entre TS et Java, ayant l'impression de se retrouver dans un environnement familier. On a mis en place une code review systématique et j'ai pu observer de près leur montée en compétences.

Après ces quelques mois, voilà le bilan: le langage est apprécié par l'équipe (le framework beaucoup moins mais c'est une autre histoire) ; le typage statique s'avère utile, davantage dans son rôle d'auto-documentation du code plutôt que de prévention de bugs. La norme ES6 est une bénédiction tant elle simplifie radicalement le code un peu partout.

Le bilan est donc globalement positif, mais il y a quand même quelque-chose qui me gène: j'ai l'impression qu'en apprenant ce TypeScript-like, mes collègues en viennent à désapprendre le JS. Ils utilisent désormais presque exclusivement des classes, quitte à en déclarer beaucoup trop qui ne servent qu'une fois alors que des objets littéraux feraient parfaitement l'affaire. On a également beaucoup d'héritage avec class extends, alors que je m'étais juré de favoriser la composition et de limiter les hiérarchies d'objets. Et j'ai beau encourager un style de programmation fonctionnelle, la codebase actuelle est très orientée OOP classique avec beaucoup d'objets mutables et un usage omniprésent de this. Bref j'ai l'impression de bosser sur un projet Java / C#, et ça ne me plaît pas beaucoup. Vous connaissez le proverbe "Quand on a qu'un marteau, tout ressemble à un clou" ? Eh bien c'est à peu près ce qui se passe ici selon moi: toutes les nouveautés TS sont utilisées abusivement et le JS vanilla semble délaissé.

J'en conclus que TypeScript va beaucoup diviser les opinions des développeurs selon leur background. Je pense que le typage fort n'est plus le fer de lance de TypeScript, contrairement à ce que son nom pourrait laisser croire. Une majorité des devs accepte l'idée qu'un typage fort optionnel est bénéfique, mais TS est loin d'être la seule option pour ça: Flow, Elm, Kotlin, ObjectModel (celui-là est de moi ^^). Non, s'il faut caractériser TypeScript, c'est surtout l'expérience de développement familière aux devs Java et C# qui va sans doute séduire les uns et repousser les autres.
4  0 
duplaisir111
Avatar de duplaisir111
Candidat au Club https://www.developpez.com
Le 22/09/2016 à 12:21
Vu la communauté derrière Angular, on pouvait bien s'y attendre.
De plus après avoir parcouru l'essentiel de TypeScript je me suis bien rendu compte qu'il facilite l'écriture, la lecture, et la compréhension du code, bref de quoi retrouver les joies de la POO.
Je compte bien l'adopter.....
1  0 
sekaijin
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 24/09/2016 à 17:00
JSweet est fait pour tes collègues
http://www.jsweet.org/
A+JYT
1  0 
yahiko
Avatar de yahiko
Rédacteur/Modérateur https://www.developpez.com
Le 24/09/2016 à 19:39
Pour simplifier, disons que tu as utilisé Flow (et non TypeScript), ce qui est relativement différent (Type checker vs compilateur).
Ton feedback dans l'absolu est intéressant, mais c'est ta manière de ramener tes conclusions à TypeScript qui me gène alors que tu n'utilises pas TypeScript.

Après, loin de moi l'idée de te convertir à TypeScript. Si tu es content avec Flow, je ne peux que t'encourager à continuer avec. C'est mieux (dans le sens qualité logicielle) que le plain JavaScript de toute manière.
Aussi, rappelons que les classes ont été introduites avec ES6, ce n'est donc pas une spécificité de TypeScript (même si la POO en TypeScript y est bien plus développée). Les gens qui veulent faire de la POO avec beaucoup d'héritage peuvent déjà le faire sans TypeScript.
1  0 
SylvainPV
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 25/09/2016 à 14:09
En fait on a pas mis Flow dans le build, mais on a configuré notre IDE (license Webstorm pour toute l'équipe) pour valider à la volée dans l'éditeur et bénéficier de l'autocomplétion. Le build Babel sert uniquement à retirer ces types avant la conversion ES5. Du coup je ne sais pas si ça a vraiment changé tant que ça l'expérience de développement. Il faut dire qu'on a très rarement eu des erreurs de typage à partir du moment où a des conventions de nommage très strictes et des classes pour décrire tout ce qu'on manipule. Si ça ne tenait qu'à moi, j'aurais préféré intégrer ObjectModel notamment pour valider les JSON de nos web services. C'est là qu'on a eu le plus de soucis jusqu'ici. Après on peut toujours mettrer Flow dans le build sans pour autant typer explicitement partout (l'inférence de type de Flow est déjà excellente en soi).

C'est vrai qu'on a pas besoin de TS pour faire de la POO classique en JS. Peut-être qu'on aurait eu le même résultat si on était parti sur du ES6 vanilla, va savoir. Sur ce point j'ai l'impression que c'est davantage Angular qui nous a influencé.
1  0 
SylvainPV
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 25/09/2016 à 18:57
Non tu as mal compris, on utilise bien Flow mais par le biais de file watchers configurés dans Webstorm. Même chose pour les linters JSCS et Stylelint. Toutes les validations ont lieu au sein de l'éditeur, directement quand on modifie le code source. C'est une fonction directement intégrée sur certains éditeurs gratuits comme Nuclide. Pour avoir essayé rapidement TypeScript sur Webstorm, je n'ai pas eu l'impression que l'expérience soit sensiblement différente.

Et on a bien Babel comme compilateur pour supprimer les éléments non-standards et transpiler en ES5, mais on a essayé de réduire au maximum la phase de build pour avoir une expérience de dev fluide.
1  0 
SylvainPV
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 26/09/2016 à 11:13
Je n'ai pas plus confiance en l'avenir de Flow non plus, mais j'ai ce plugin Babel au build qui retire automatiquement les indications de type. Et les indications de type sont totalement optionnelles, elles n'influent pas sur la logique du code. Donc si un jour je dois me débarasser de Flow, je lance ce plugin et hop, j'ai du JS vanilla sans aucune retouche à faire

Pour d'autres syntaxes comme les décorateurs, là pas le choix il faudra réécrire le code si on souhaite s'en débarrasser. C'est le prix à payer pour pouvoir utiliser Angular 2 sans se lamenter devant le manque de doc sur la partie JavaScript. TS apporte de nouvelles fonctionnalités, mais c'est justement ça qui rend plus compliqué l'éventuel retour à du JS classique après coup, et c'était là mon point de vigilance qui m'a amené à faire ce choix là.

Reprendre le code source généré par TypeScript compiler n'aurait pas été envisageable puisque l'on souhaitait une codebase ES6. Aussi, même si l'output est relativement propre comparé à d'autres compilateurs, il faut pas se mentir, c'est loin d'être l'idéal non plus pour servir de nouvelle base. Une autre raison qui nous a fait écarter TypeScript est qu'il n'était pas tout à fait au point question support ES6 comparé à Babel. Certains codes passaient sous Babel mais pas sous TS. J'ignore si ça a été amélioré depuis, je vois qu'il est à 59% sur http://kangax.github.io/compat-table/es6/
1  0 
SylvainPV
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 26/09/2016 à 14:11
On a pas vécu les mêmes expériences, simplement J'ai fait l'expérience de faire la maintenance d'un vieux projet CoffeeScript et c'était mission impossible pour avoir du support, plein de dépendances n'étaient plus maintenues. Il est en train d'arriver la même chose à un collègue qui a repris un prototype écrit en Dart et où ils ont décidé de faire un rewrite complet en JS. J'ai vu trop souvent des conférences où on annonce le super langage qui va remplacer JS, où les gens excités démarrent leurs projets avec et deux ans plus tard ils regrettent leur décision.

Peut-être que je me trompe pour TS, il a l'air mieux parti que les autres, mais on disait la même chose à l'époque pour CoffeeScript. Je ne sais pas si tu as connu la "grande époque CoffeeScript" dans ton milieu professionnel. A l'époque j'ai connu une personne qui faisait preuve de beaucoup d'engouement pour CS, le même engouement dont tu fais preuve pour TS aujourd'hui de par tes nombreuses publications sur le sujet. Et il avait des arguments très convaincants, je me rappelle d'une présentation qui avait conquis tout le monde en voyant tous les avantages. Seulement voilà, aujourd'hui il code son front en JS.
1  0 
SylvainPV
Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 27/09/2016 à 0:09
@Songbird: Qu'est-ce que tu veux dire par "ça ne me dérangerait absolument pas que JS soit totalement standardisé comme peuvent l'être ses surcouches" ? Je ne sais pas trop quelle définition tu as de "standard", mais dans mon esprit c'était plutôt JavaScript qui suivait le standard ECMAScript tandis que les surcouches étaient libres d'évoluer n'importe comment, puisque l'éditeur fournit à la fois le langage et l'implémentation.

Concernant la techno qui s'essoufle en parlant de JavaScript, c'est clair que je ne partage pas du tout la même vision que toi en voyant le graphe publié par yahiko Depuis ES6 le JS est métamorphosé, et on a maintenant des mises à jour annuelles de la norme ECMAScript. D'après moi le langage a dormi pendant 15 ans, a été un peu remué par la révolution mobile, et s'est complètement reveillé ces dernières années. Aujourd'hui il n'a jamais été aussi populaire et actif, ce qui n'est pas pour me déplaire.

@yahiko: Certes, les langages ne disparaissent pas, ce sont les développeurs qui les pratiquent qui disparaissent. C'est ce qui est arrivé avec CoffeeScript: des libs open source abandonnées par leur auteur et pas de gens compétents disponibles en interne pour les reprendre. L'adoption de masse est essentielle en entreprise, on ne peut pas simplement choisir un langage parce qu'il est meilleur, sinon je ferais du Elm
Eh oui, je fais partie de la "secte" qui pense que le typage fort dynamique est plus adapté pour JS que le typage statique, trop limité dans son champ d'action. Je voulais d'ailleurs bosser sur une vidéo explicative pour ObjectModel prochainement, ce sera peut-être l'occasion de détailler mon point de vue plus clairement.
1  0 
Songbird
Avatar de Songbird
Membre expert https://www.developpez.com
Le 27/09/2016 à 23:42
Bonjour,

Vu de l'extérieur, en tant que généraliste non spécialiste javascript, CoffeeScript par exemple m'a toujours paru beaucoup plus confidentiel, et d'un autre côté Dart a eu pas mal de critiques dès sa sortie à tel point que sans sa paternité google on peut se demander s'il aurait suscité autant d'intérêt (dont la grande part de croyance chez les débutants de considérer google comme Dieu le père).
Sans trop m'avancer sur le sujet, je pense que c'est principalement dû au fait que Google soit le développeur de Dart qui a suscité pas mal de rejets. (c'est l'impression que cela me donne lorsque je vois les intervenants de certains forums/actualités)

C'est également, en premier lieu, le souhait d'intégrer une implémentation de la VM dart dans tous les navigateurs qui n'a pas beaucoup plu, même si, sur le papier, je trouve cette idée pas si mauvaise.
1  0 
Commenter Signaler un problème