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, Rédacteur/Modérateur

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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de grunk grunk - Modérateur https://www.developpez.com
le 15/09/2016 à 8:55
Angular2 n'est sans doute pas étranger au succès de Typescript puisqu'il en fait son langage par défaut (et tant mieux).

Le seul inconvénient de TS pour moi est la nécessité d'écrire ou de trouver les bon typings pour les lib tierces afin de les intégrer correctements. Pas de souçis sur les grosses libs qui les proposes mais dès qu'on utilise quelque chose d'un peux exotique ca devient la galère.
Avatar de LSMetag LSMetag - Membre expert https://www.developpez.com
le 15/09/2016 à 9:04
J'ai vu que maintenant ils font des générateurs de typings. Après je ne sais pas si il fonctionnent suffisamment bien. Regarde dans les packages nuget.
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 15/09/2016 à 11:48
Il s'agit peut-être de celui-ci : https://github.com/Microsoft/dts-gen
C'est encore un projet à l'état expérimental, que je n'ai pas encore testé.

Après, pour certaines libs un peu confidentielles (et certaines deadlines serrées ^^'), la solution du typage du namespace en any dépanne toujours. Même si c'est moins élégant qu'un typage exact, ce n'est pas bloquant en TypeScript.
Avatar de LSMetag LSMetag - Membre expert https://www.developpez.com
le 15/09/2016 à 13:41
Il y a aussi une implémentation de Yeoman Generator : https://www.npmjs.com/package/generator-typings
Avatar de tmcuh tmcuh - Membre du Club https://www.developpez.com
le 15/09/2016 à 19:49
En même temps les professionnel windows application publie très peu leur code contrairement au web ou le fait de partager est presque un devoir pour corriger les bugs et stabiliser la multitude de technologie qui existe. Les mecs du web sont enfermé de carcan en carcan et n'ont pas d'autres choix que de partager.
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 19/09/2016 à 15:24
Ha !?

C'est nouveau ça ce n'est pas ce que je constate depuis 1994 que je travaille dans le monde du web.
Avatar de duplaisir111 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.....
Avatar de SurferIX SurferIX - Membre chevronné https://www.developpez.com
le 23/09/2016 à 10:27
A chaque fois que je vois Python autant devant Php, ça me conforte dans ma décision de laisser tomber définitivement Php au profit de Python.
Avatar de SylvainPV 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.
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 24/09/2016 à 3:41
Dans la mesure où, si j'ai bien compris, ce que tu as mis en place n'est pas vraiment TypeScript, mais un erzatz, je reste un peu sceptique quant à la portée de ton retour d'expérience.
Il serait plus honnête dans le sens plus transparent si tu partageais plus en détails tes presets Babel pour juger de la réelle proximité avec le compilateur TypeScript.
Avatar de Songbird_ Songbird_ - Rédacteur/Modérateur https://www.developpez.com
le 24/09/2016 à 4:15
Salut,

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.
En dehors des classes, je ne vois pas trop ce que les développeurs Java ont de familier avec TS, sachant qu'il est possible de mélanger de la programmation procédurale et OO, alors qu'en Java non, et le typage y est très faible, par rapport à java. (même le système d'imports n'a rien de familier, à mon goût)

En revanche Dart ressemblerait plus à un Java-like, mais il en reste loin. (encore heureux, dans un sens)
Avatar de sekaijin 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
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 24/09/2016 à 18:42
@yahiko: ce preset là : https://github.com/shuhei/babel-preset-angular2

@Songbird: ben écoute "Ah ça ressemble à Java" est le premier commentaire que j'ai eu de leur part. Je pense que c'est principalement à cause des classes, du typage statique et des annotations. On ne fait quasiment plus de procédural, le framework n'est pas pensé en ce sens.
Avatar de yahiko 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.
Avatar de SylvainPV 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é.
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 25/09/2016 à 14:49
Si vous n'utilisiez ni Flow, ni TypeScript, comment pouvez-vous détecter vos éventuels bugs sur le typage ? C'est juste une question parce que sans compilateur ni type checker, j'ai un peu de mal à voir comment on peut conclure que les annotations de typage ne corrigent aucun ou très peu de bugs. Si vous ne vous basez que sur le support WebStorm de Flow, je trouve que c'est un peu léger comme validation. Mais je peux me tromper.
Avatar de SylvainPV 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.
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 26/09/2016 à 1:37
Citation Envoyé par SylvainPV Voir le message
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.
Tu utilises donc Flow, même si tu ne l'inclus pas dans le build. Mais en quoi selon toi Flow serait-il plus rassurant que TypeScript à terme ?
Personnellement, je ne vois pas très bien pourquoi l'un serait plus pérenne que l'autre (même si j'ai plutôt l'impression que TypeScript me semble mieux partit pour), d'autant que le code JavaScript généré par TypeScript peut tout à fait être repris comme nouveau code source, même si pour le moment, je n'ai jamais observé de retour en "arrière".

Concernant les principales différences ("expérience" entre TypeScript et Flow, ce pourrait faire l'objet d'un article en soi, mais Flow n'ajoute pas de construction syntaxique qui ne préexiste pas déjà avec ES6. C'est un type checker. TypeScript lui étend la syntaxe de JavaScript au delà de ES6 en permettant par exemple l'encapsulation, les enum, les namespaces, etc. Aussi, TypeScript peut se substituer à la fois à Flow et à Babel, dans la plupart des cas. Aussi, ce qui est appréciable avec TypeScript, est l'homogénéité dans l'outillage proposé par les différents IDE et éditeurs (autocomplétion, analyse syntaxique à la volée, refactoring, etc). Dans la mesure où ces fonctionnalités sont fournies par le compilateur lui-même et non par l'IDE, cela permet de bénéficier des mêmes fonctionnalités qu'on soit sur Visual Studio, Visual Studio Code, Atom, Eclipse, Sublime, WebStorm, etc. Pour bénéficier de ces fonctionnalités avec Flow, il me semble que le choix d'IDE/éditeur est plus restreint.

Sinon, même si tu n'as pas utilisé TypeScript dans ton projet, je trouve que ça va dans le "bon" sens. J'observe autour de moi de nombreux développeurs qui s'intéressent à TypeScript et au typage en général pour des projets JavaScript ce qui est très positif. Les mentalités évoluent. Je pense que le typage finira par s'imposer dans les prochaines années parmi la communauté des développeurs Web, on en avait déjà discuté il me semble.
Avatar de SylvainPV 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/
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 26/09/2016 à 11:28
Entre nous, et on ne va pas se mentir aussi, je ne vois pas de raison pourquoi vous retourneriez au JS Vanilla. Je n'ai jamais observé de retour en arrière dans les projets TS (pour Flow je ne sais pas mais on va dire que c'est pareil). Tes craintes à mon avis sont mal placées.
Sur la transpilation ES6 vers ES5, TS a bien progressé depuis, surtout qu'au pire il est possible de chaîner Babel si vraiment on tient à certaines syntaxes ES6 qui ne sont pas encore supportées par TS.
Avatar de SylvainPV 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.
Avatar de yahiko yahiko - Rédacteur/Modérateur https://www.developpez.com
le 26/09/2016 à 21:10
Même si je n'ai jamais été pas un fervent admirateur de CoffeeScript, et c'est un euphémisme, il me semble que ce langage continue d'évoluer et reste populaire auprès d'une part non négligeable de la communauté des développeurs Web. Le manque de support que tu évoques me laisse donc perplexe. Et tu pouvais repartir sur le résultat JS qui bien qu'étant légèrement moins "propre" que le code produit par TypeScript reste à mon sens exploitable par un humain. Après, les dépendances non maintenues, ça existe aussi en JavaScript (et dans d'autres langages mainstream comme Java ou C++). D'ailleurs c'est souvent des modules internes, home made, qui sont les premiers touchés par ce syndrome. C'est donc souvent moins affaire de langage que de développeurs (et de documentation suffisante...).

Je connais bien cet argument du "et si tel langage disparaît". Il existe depuis l'invention de l'informatique ^_^
Tout d'abord un langage ne disparaît jamais. Il faudrait d'ailleurs réfuter systématiquement cette assertion.
Ensuite, en général, ce qui freine les migrations et les évolutions d'une base de code, ce n'est pas parce qu'un langage est resté figé à une norme X depuis Y années, mais avant tout parce que la qualité logicielle au sens large de cette base de code est insuffisante pour évoluer.

Enfin, je conclurai sur ta remarque son mon "enthousiasme" pour TypeScript. Je fais moins la promotion de TypeScript en tant que tel que la promotion d'une évolution des mentalités chez les développeurs JavaScript qui rejettent à tort (à mon sens) l'idée du typage et des constructions syntaxiques qui ne sont pas propre à JS. C'est surtout en réaction à un certain sectarisme dans le milieu que je me plait à titiller ce petit monde. Ca ne plaît pas à tout le monde, je peux le constater autour de moi. Mais je pense que c'est salutaire
Avatar de Songbird_ Songbird_ - Rédacteur/Modérateur https://www.developpez.com
le 26/09/2016 à 21:54
Salut,

Enfin, je conclurai sur ta remarque son mon "enthousiasme" pour TypeScript. Je fais moins la promotion de TypeScript en tant que tel que la promotion d'une évolution des mentalités chez les développeurs JavaScript qui rejettent à tort (à mon sens) l'idée du typage et des constructions syntaxiques qui ne sont pas propre à JS. C'est surtout en réaction à un certain sectarisme dans le milieu que je me plait à titiller ce petit monde. Ca ne plaît pas à tout le monde, je peux le constater autour de moi. Mais je pense que c'est salutaire
Je suis plutôt d'accord avec cette partie de ton message. Moi ça ne me dérangerait absolument pas que JS soit totalement standardisé comme peuvent l'être ses surcouches, qu'il bénéficie d'un typage statique (mais optionnel pour ceux qui ne veulent pas l'utiliser), d'un type checker, etc. Je ne vois pas vraiment où est le mal de faire évoluer une techno qui s’essouffle dans sa forme actuelle.
Avatar de SylvainPV 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.

Avatar de Songbird_ Songbird_ - Rédacteur/Modérateur https://www.developpez.com
le 27/09/2016 à 4:33
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"
Ce que j'entends par "standard", c'est une techno que tout le monde ne gère pas à sa sauce, il n'y a pas 10k implémentations différentes de son moteur, ... Un langage qui possède un véritable standard, quoi. (mais oui effectivement ES6 est arrivé et a sauvé un peu la mise, toujours est-il qu'il n'existe toujours pas de véritable système d'import (sauf erreur de ma part))

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.
Bah justement, jusqu'ici les surcouches imposent directement les fonctionnalités de l'ES6 (qui, rappelons-le, ne sont que de simples formalités dans la plupart des langages) et plus si affinité, mais on avait au moins les features de la dernière version du standard. JavaScript suit ce standard, certes, mais nombre de ressources (et de sites) utilisent encore des fonctionnalités obsolètes, ce qui me pousse à dire que l'ES6 sera respecté quand une nouvelle version du standard sortira, ce qui n'aide vraiment pas.

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.
(Je ne vise pas JS, donc ne me jetons pas des cailloux )

Popularité n'est pas forcément un signe de qualité, attention à ne pas confondre.
JavaScript est populaire car connu et enseigné partout, ça ne veut pas dire qu'il est d'une certaine qualité pour autant.

En revanche lorsque je parle du fait de "s'essouffler", je ne parle pas vraiment du désamour des développeurs à son égard, mais bien du fait que JavaScript est obligé de ramer comme un damné pour évoluer et obtenir des fonctionnalités que des surcouches de ce dernier disposent déjà nativement et pour une grande majorité d'entre-elles.
Avatar de TiranusKBX TiranusKBX - Expert confirmé https://www.developpez.com
le 27/09/2016 à 18:40
@Songbird_ le import est prévus mais pour le moment aucun navigateur ne l'a implémenté vus la complexité que ça demande
Avatar de Songbird_ Songbird_ - Rédacteur/Modérateur https://www.developpez.com
le 27/09/2016 à 19:27

Citation Envoyé par TiranusKBX Voir le message
@Songbird_ le import est prévus mais pour le moment aucun navigateur ne l'a implémenté vus la complexité que ça demande
Tu aurais un lien ?
Avatar de ABCIWEB ABCIWEB - Expert éminent https://www.developpez.com
le 27/09/2016 à 21:46
Bonjour,

Concernant TypeScript, cela me semble bien parti en effet.

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).

L'adoption de TypeScript par Angular et des critiques globalement positives sans point de crispation particulier, me font dire que je pourrais adopter cette surcouche sans appréhension particulière, un peu comme j'avais adopté jquery il y a quelques années mais pour d'autres besoins.

Citation Envoyé par SurferIX Voir le message
A chaque fois que je vois Python autant devant Php, ça me conforte dans ma décision de laisser tomber définitivement Php au profit de Python.
Ce n'est que le classement GitHub. Python est plus généraliste et très utilisé en entreprise ce qui le favorise naturellement dans les dépôts GitHub. Si l'on se réfère plus particulièrement au web les résultats sont très différents. Pour dire que si Python est sans doute plus intéressant "globalement", c'est moins évident pour le web. Je me demande s'il est judicieux de vouloir comparer frontalement ces deux langages en dehors de tout contexte.
Avatar de Songbird_ Songbird_ - Rédacteur/Modérateur 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.
Avatar de Paleo Paleo - Membre confirmé https://www.developpez.com
le 01/10/2016 à 13:09
Citation Envoyé par SylvainPV Voir le message
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é.
Aujourd'hui le "JS vanilla" inclue la POO classique à base de classes. Tes collègues n'utilisent certes pas correctement JavaScript, ils se cantonnent à un sous-ensemble du langage, les classes. Pour ma part j'interdis l'héritage à mon équipe sauf cas exceptionnel qu'il faut alors bien m'expliquer car je valide rarement.

Cela dit, yahiko a raison, tu n'as pas utilisé TypeScript. La grande force de TypeScript, ce sont les interfaces. Ces interfaces qui justement donnent du typage aux objets POJO que tu apprécies.

Citation Envoyé par SylvainPV Voir le message
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
Alors qu'avec TypeScript, tu ne dépendrais pas d'un plugin dont la maintenance est hypothétique. Il te suffirait de prendre le code compilé, ce qui restera possible tant que le langage existera. TypeScript, sur ce plan-là, est sans risque, au même titre que SCSS par rapport aux CSS par exemple. Le code généré est tellement proche de l'original que les développeurs peuvent embrayer dessus sans difficulté.

Citation Envoyé par SylvainPV Voir le message
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.
Un Flow un peu tweaké ne vaut pas un TS-like. Flow est à JavaScript ce que Hack fut à PHP 5 : une erreur d'orientation de la part d'une boite qui a les moyens de persister dedans. Mais les interfaces de TypeScript sont concurrentes à ton bébé. Il est possible qu'il y ait là de quoi te faire passer à côté de TypeScript, sincèrement, c'est dommage.
Avatar de Paleo Paleo - Membre confirmé https://www.developpez.com
le 01/10/2016 à 15:06
Citation Envoyé par sekaijin Voir le message
JSweet est fait pour tes collègues
http://www.jsweet.org/
A+JYT
La première ligne du premier exemple :

Code : Sélectionner tout
package animation;
… traduite en JS par :

Code : Sélectionner tout
1
2
3
4
var animation;
(function (animation) {
  // …
})(animation || (animation = {}));
… et en TS par :

Code : Sélectionner tout
1
2
3
module animation {
	// …
}
C'est obsolète.
Je déconseille.
Il existe des concepts en TypeScript/JavaScript qui n'ont pas d'équivalents en Java ou bien dont l'application est plus large.

Les modules ES6 en sont un. Ils remplacent en mieux les packages Java, ils ne sont pas un concept équivalent. Le concept JS équivalent est effectivement une variable globale, comme dans l'exemple, c'est-à-dire la plupart du temps une mauvaise pratique.

Et aussi, en TS, ce mot-clé "module" est devenu "namespace".
Avatar de sekaijin sekaijin - Expert éminent https://www.developpez.com
le 01/10/2016 à 16:09
le propos n'est pas d'apporter dans java les capacité des langages TS ou JS mais de permettre à des développeurs java de travailler en java pour produire des application côté client (en ts ou js). les développeurs java veulent continuer à utiliser les concepts java.

quant à la traduction elle dépends du niveau EcmaScript demandé à la compilation.

il ne s'agit pas non plus comme d'autre solution de faire fonctionner une JVM dans le navigateur.

il s'agit donc simplement d'utiliser les outils java avec les concepts java pour produire des applications JS.
je réponds donc à la personne qui dit que ces développeurs java on envie de rester dans leur univers que jsweet est une solution pour eux.

lorsque tu programme en C++ tu ne regarde pas de près quels sont les compromis que fait ton compilateur et si le binaire produit n'est pas des plus orthodoxe par rapports au toutes dernières méthodes ce qui t'intéresse c'est que ça fonctionne, que ça n'occupe pas trops de ressources, que ça a les perf attendue et que ça ne plante pas.
ton compilateur peut produire un binaire complètement contraire aux bonnes pratiques des développeurs en assembleur, tu n'en a rien à faire.

Quant à ouvrir un exemple ES5 et dire je déconseille d'utiliser cette techno parce que en ES6 blabla... c'est un peut court.
A+JYT
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 01/10/2016 à 16:31
Citation Envoyé par Songbird
Ce que j'entends par "standard", c'est une techno que tout le monde ne gère pas à sa sauce, il n'y a pas 10k implémentations différentes de son moteur
C'est curieux, j'avais l'exacte définition contraire de standard. Pour moi, un standard est un ensemble de spécifications établies par un organisme dit de standardisation tel que Ecma International, mais qui ne fournit pas d'implémentation de ces spécifications de manière à préserver la concurrence. Ainsi, toute entreprise respectant ces normes peut affirmer "suivre le standard" tout en ayant des performances différentes, par exemple les périphériques USB ou les normes Wi-Fi. S'il n'y a qu'une seule implémentation et qu'elle est faite par la même équipe que celle qui définit le langage, on ne peut pas parler de standard selon moi. Un spécialiste technico-lexico peut confirmer ?

Citation Envoyé par Tarh_ Voir le message
Aujourd'hui le "JS vanilla" inclue la POO classique à base de classes. Tes collègues n'utilisent certes pas correctement JavaScript, ils se cantonnent à un sous-ensemble du langage, les classes.
Oui enfin les classes ES6 sont quand même très écrémées par rapport aux les classes TS. Pour rappel, en ES6 on a pas de définition de propriétés dans les classes, ni de mots-clés public/private, ni d'annotations. Ce n'est pas tout à fait comparable.

Citation Envoyé par Tarh_ Voir le message
Alors qu'avec TypeScript, tu ne dépendrais pas d'un plugin dont la maintenance est hypothétique. Il te suffirait de prendre le code compilé, ce qui restera possible tant que le langage existera. TypeScript, sur ce plan-là, est sans risque, au même titre que SCSS par rapport aux CSS par exemple. Le code généré est tellement proche de l'original que les développeurs peuvent embrayer dessus sans difficulté.
Je ne vois pas en quoi TS serait plus sûr que Flow question pérennité. Les problématiques de maintenance sont les mêmes entre Flow et TSC, les entreprises qui portent ces projets ont la même ampleur, tout comme la communauté d'utilisateurs (Flow est très populaire dans la sphère React). Quant à repartir d'une codebase à partir du résultat d'une transpilation, je pense que vous rêvez un peu. On voit régulièrement le code en sortie lors du debug sur navigateur et c'est très difficile de faire le parallèle avec le code initial. Si vous avez un exemple en tête où des gens ont réussi à faire ça sur un projet conséquent, ça m'intéresse de voir comment ils ont fait.
Avatar de Paleo Paleo - Membre confirmé https://www.developpez.com
le 01/10/2016 à 18:18
Citation Envoyé par SylvainPV Voir le message
Oui enfin les classes ES6 sont quand même très écrémées par rapport aux les classes TS. Pour rappel, en ES6 on a pas de définition de propriétés dans les classes, ni de mots-clés public/private, ni d'annotations. Ce n'est pas tout à fait comparable.
Oui, c'est vrai, mais l'usage est proche. Et les classes TS sont d'ailleurs compilées en classes JS.

Citation Envoyé par SylvainPV Voir le message
Quant à repartir d'une codebase à partir du résultat d'une transpilation, je pense que vous rêvez un peu. On voit régulièrement le code en sortie lors du debug sur navigateur et c'est très difficile de faire le parallèle avec le code initial.
Parce que le code est compilé pour EcmaScript 3 ou 5. Essayez de le compiler pour ES6 (option de compilation "--target". Vous obtiendrez ce que vous cherchez.
Avatar de Paleo Paleo - Membre confirmé https://www.developpez.com
le 01/10/2016 à 18:30
Citation Envoyé par sekaijin Voir le message
il s'agit donc simplement d'utiliser les outils java avec les concepts java pour produire des applications JS.
je réponds donc à la personne qui dit que ces développeurs java on envie de rester dans leur univers que jsweet est une solution pour eux.
Ah, effectivement, j'aurais dû mieux lire le sous-titre, j'avais compris de travers qu'il s'agissait d'un site d'évangélisation pour aider à passer à la programmation JS les développeurs Java.
Contacter le responsable de la rubrique Accueil