État de JavaScript en 2019 : les développeurs aiment un peu plus React, Angular est en déclin

État de JavaScript en 2019 : les développeurs aiment un peu plus React, Angular est en déclin,
un groupe de développeurs pense que JS est « trop complexe »

L’année 2019 prend fin et Sacha Greif et Raphaël Benitte viennent de publier leur rapport annuel sur l’état de JavaScript et de son écosystème en entier. Environ 11 millions de développeurs utiliseraient JavaScript, et bien qu'il soit difficile de trouver tout le monde et de leur demander ce qu'ils aiment dans ce langage, l'étude “State of JavaScript 2019” a interrogé plus de 21 000 développeurs JS sur leurs frameworks, outils et fonctionnalités préférés. Les résultats ont montré comment que l’écosystème JS a évolué et quels outils sont les plus utilisés en 2019.

Le rapport 2019 sur l'état de JS a révélé les principaux frameworks de travail du langage, les données démographiques sur les utilisateurs et d’autres données importantes. Qu'on l'aime ou qu'on le déteste, le langage continue de gagner du terrain et son écosystème ne cesse de grandir. Il est essentiel au développement moderne et est le premier langage de programmation sur GitHub depuis 2014, le langage Python ayant pris la deuxième place cette année devançant ainsi Java. Faisons un petit tour de ce qui est ressorti du sondage cette année.

TypeScript gagne de nouveau en importance et est classé premier en matière de satisfaction

TypeScript est un surensemble typé qui se compile en JS pur. 2018 et 2019 ont été des années majeures pour TypeScript et son adoption. Selon l’étude, si l'on remonte en 2016, la notoriété de TypeScript auprès des développeurs était déjà de 97 %, mais l'intérêt dépassait à peine la barre des 50 %. En 2019, tous les développeurs qui ont répondu à l'enquête savent ce qu'est TypeScript et un pourcentage impressionnant de 58,5 % l'utiliseraient à nouveau. De même, 89 % des répondants se sont déclarés satisfaits de TypeScript. Il s'est classé au premier rang en matière de satisfaction, d'intérêt et de notoriété par rapport aux autres langages qui compilent en JS (Elm, Rason, ClojureScript et PureScript).

Pièce jointe 526804

React devient l’outil (framework front-end) préféré des développeurs front-end et l’enthousiasme pour Angular continue de baisser

En ce qui concerne les frameworks et les bibliothèques front-end, Angular et React sont deux des plus grands noms. L'année dernière, il a été constaté une baisse de la satisfaction à l'égard d'Angular. Cette année, il poursuit sa tendance à la baisse. Environ 35,8 % des développeurs ont déjà utilisé Angular, mais ne l'utiliseront plus. En comparaison, 21,9 % ont utilisé Angular et ont déclaré vouloir l’utiliser à nouveau. Cependant, ce pourcentage pourraient peut-être évoluer l’année prochaine lorsque la version stable d'Angular v9 sera publiée.

Pièce jointe 526801

Dans le cas de React, 71,7 % des développeurs l’ont utilisé et ont déclaré vouloir l’utiliser à nouveau. Il s'agit d'une légère augmentation de la satisfaction par rapport aux années précédentes. L'année 2019 s'est révélée être une année phare pour React. Plus tôt cette année, npm a mené une enquête qui a révélé que 63 % des développeurs de JS écrivent du code React. Un graphique résumant tout cela illustre aussi la montée du framework de test JavaScript Jest, avec un impressionnant classement de satisfaction de 96 %, le plaçant bien devant Mocha.

Les développeurs JavaScript apprécient également GraphQL plus que Redux pour la couche de données, et Express devant Next.js pour le back-end. Par ailleurs, même si certains développeurs continuent toujours à se plaindre d’Electron, le framework JS pour concevoir des applications pour le bureau n’a pas perdu en importance pour autant. La satisfaction des développeurs à l'égard d'Electron est passée de 93 % à 86 %, mais le sentiment général est toujours plus élevé que celui de React Native (82 %). Enfin, Svelte est en hausse, mais encore obscure pour beaucoup.

Pièce jointe 526806

Svelte est définitivement le “nouveau framework cool sur le bloc” de 2019. Plus probablement, c'est la sortie de Svelte 3 en avril et le buzz qui a suivi qui ont suscité l'intérêt. Svelte est une nouvelle approche radicale pour créer des interfaces utilisateur. Alors que les frameworks traditionnels comme React et Vue effectuent la majeure partie de leur travail dans le navigateur, Svelte transforme ce travail en une étape de compilation qui se produit lors de la construction de l'application. De tous les outils frontaux, Svelte est celui qui suscite le plus d'intérêt.

Cependant, il est le moins connu. Svelte est en tête de l'enquête pour l'intérêt et au coude à coude avec React pour la “satisfaction”. Comme Svelte, WebAssembly (WASM) n'a pas encore atteint les masses. Tout le monde parle de la WASM, mais très peu de personnes l'utilisent. À la différence des composants Web, l'enthousiasme par rapport à WASM est presque universel. Cela dit, il semble que beaucoup attendent simplement que la technologie mûrisse. Il est d’ailleurs devenu cette année le 4e langage pour le développement Web.

Les outils du métier

Le rapport 2019 sur l’état de JS s’est également intéressé à ce que les développeurs de JS peuvent ajouter à leur boîte à outils. Les répondants ont été interrogés sur les divers outils qu'ils utilisent pour coder et sur les ressources inestimables qu'ils utilisent.

• Lodash et Moment.js : ces deux bibliothèques d'utilitaires JS sont les deux plus utilisées par les développeurs. Lodash fournit de l'aide pour travailler avec des tableaux, des nombres, des objets et des chaînes de caractères et Moment.js fournit une bibliothèque pour afficher et manipuler des dates ;
• Visual Studio Code : de loin, VS Code est l'éditeur de texte le plus utilisé. Visual Studio Code fonctionne avec un grand nombre de langages, y compris JavaScript et TypeScript ;
• Brave : bien que Chrome soit le navigateur le plus utilisé pour le développement, une mention honorifique est décernée cette année à Brave. Environ 836 développeurs ont déclaré qu'ils travaillent principalement dans le navigateur Brave ;
• Webpack : regroupez vos scripts, vos ressources et vos images avec Webpack, l'outil de construction JS le plus utilisé ;
• Stack Overflow : ce n'est pas une surprise, mais Stack Overflow est l'endroit où les développeurs JS vont quand ils ont besoin d'aide pour un problème délicat, même s’il est de plus en plus décrié de copier et de coller du code à partir de Stark Overflow. Le Developer Network/MDN de Mozilla reçoit une mention honorable en tant que deuxième ressource la plus consultée.

À quoi ressemble le développeur JS moyen ?

Le rapport 2019 sur l’état de JS a également fait mention de ce à quoi ressemble le développeur JS moyen en 2019. Voici ce que les auteurs du rapport ont résumé sur la question.

• JS + CSS : dans l'ensemble, les développeurs JS sont également compétents en CSS. Au moins 90 % des répondants ont déclaré avoir une connaissance intermédiaire du CSS ou mieux. Environ 39,9 % se considèrent même comme des experts en CSS et peuvent créer un front-end à partir de zéro ;
• le JavaScript régit le front-end : le rôle des développeurs full stack est de plus en plus important, selon le rapport. Près de la moitié (environ 48,3 %) des répondants sont des développeurs full stack. Environ 36,6% sont des développeurs front-end, alors que seulement 3,4 % se disent développeurs back-end ;
• les développeurs JS aiment aussi Python : un quart des développeurs JS multilingues programment aussi en Python ;
• Ratio des sexes : 91,3 % des répondants sont des hommes ; 6 % sont des femmes ; 0,8 % sont des non binaires, et 1,9 % des répondants ont préféré ne pas répondre. Ces chiffres peuvent ne pas refléter la réalité réelle des développeurs, car il ne s'agit que d'un seul sondage. Toutefois, l'écart entre ces chiffres est notable.

Enfin, la section Opinions du rapport a révélé que certains estiment que JavaScript est “trop complexe”. Environ 31,4 % sont d'accord et 28,3 % sont neutres sur la question. Sachant que ce sont les professionnels, c'est remarquable, bien que cela fasse sans doute référence à l'ensemble de l'écosystème des frameworks, des bibliothèques et des outils, plutôt qu'au langage lui-même. À quoi sert JavaScript ? En ce qui concerne ce groupe, 68,3 % des répondants sont d'accord pour dire que ce serait leur principal langage de programmation. Toutes les données de l’étude “State of JS 2019” sont disponibles en téléchargement sur Kaggle au format JSON.

Source : State of JS 2019

Et vous ?

:fleche: Pensez-vous que JavaScript soit un langage complexe ? Pourquoi ?

Voir aussi

:fleche: Python devance Java et devient le deuxième langage de programmation le plus utilisé par les contributeurs sur GitHub, après JavaScript

:fleche: The State Of JavaScript 2018 : l'enquête révèle que JavaScript est en pleine évolution. Voici une vue macro des technologies JS utilisées

:fleche: La version 3 de Svelte, le framework de composants graphiques, est disponible et repense la réactivité des frameworks autrement

:fleche: AlaSQL.js, une base de données SQL JavaScript pour le navigateur et Node.js, est désormais disponible et serait rapide et très flexible

:fleche: Les tendances dans les métiers de la technologie en France en 2017, une enquête réalisée par CodinGame

Citation:

---

Pensez-vous que JavaScript soit un langage complexe ? Pourquoi ?

---

C 'est un langage aussi simple que python ! Ces crétins veulent du Perl ? Du Basic ???

Angular n'est pas un framework JS. Il y a une confusion entre AngularJS et Angular, qui lui est écrit en TS (qui monte en intérêt) et passe aussi par une étape de validation/transcompilation comme Svelte.

Citation:

---

Envoyé par darklinux

C 'est un langage aussi simple que python ! Ces crétins veulent du Perl ? Du Basic ???

---

C'est bien Perl :mouarf:

Par contre les couleurs des graphes !!!

Citation:

---

Pensez-vous que JavaScript soit un langage complexe ? Pourquoi ?

---

Si tu sais faire que de l'objet, c'est normal de le trouver complexe, vu qu'il ne s'agit pas d'un langage objet (même si un peu maintenant) mais prototypé. Et quand on sait qu'il servait surtout pour le DOM à la base, ça avait du sens. Le truc c'est que des « dévs back » veulent que ça fasse comme leurs langage favoris qui ne sont qu'en objet et ne veulent pas réapprendre une nouvelle logique de programmation. :aie:

Après, j'avoue que je trouve ça bien quand il s'agit de manipuler le DOM et les structures du genres, mais pour le reste c'est quand même pas facile à appréhender. :oops:

Ce qui fait peur dans tout ce bazar, c'est la question "quelle langage/techno sera encore là dans 5 ans ?".
Visiblement, tout le monde s'en contrefiche, vu comment ça part dans tous les sens, mais bon, ce sont quand même des sous dépensés par quelqu'un, et au bout du compte, ça fait de la croissance :mrgreen:

Cette année ce sera la réécriture de l'application d'entreprise (db de 400 tables, c'est une application métier complète y compris toute la compta et hr...) d'angularjs vers react.
Svelte m'intéressait beaucoup, mais la documentation c'est zéro. Du coup ce sera react. Travailler sur un truc par essai erreur en découvrant ce qui fonctionne ou pas pour un projet perso c'est bien, mais pas pour une application de cette importance.

Citation:

---

Envoyé par RPGamer

Angular n'est pas un framework JS. Il y a une confusion entre AngularJS et Angular, qui lui est écrit en TS (qui monte en intérêt) et passe aussi par une étape de validation/transcompilation comme Svelte.

---

TypeScript n'est pas un langage c'est une extension de JavaScript.

Citation:

---

Angular n'est pas un framework JS. Il y a une confusion entre AngularJS et Angular, qui lui est écrit en TS (qui monte en intérêt) et passe aussi par une étape de validation/transcompilation comme Svelte.

---

Justement Typescript reste simplement un langage transcompilé en JS au final donc Angular (> V1) reste un framework JS...

Citation:

---

Envoyé par Marco46

TypeScript n'est pas un langage c'est une extension de JavaScript.

---

Exactement ce que m'avait dit un des dévs de TypeScript. De plus, ils essaient juste d'implémenter le futur du JavaScript avec une «*surcouche » pour le rendre accessible plus rapidement et facilement. Quand on fait du TypeScript, on fait juste du JavaScript avancé. Quand on suit un peu les évo de TypeScript et de JavaScript ça semble assez évident.

Pensez-vous que JavaScript soit un langage complexe ? Pourquoi ?

Ça dépend d'où vous placer le curseur de la complexité :aie:.
Si on se limite à la syntaxe, alors il n'est pas fondamentalement plus complexe qu'un autre et n'introduit pas de notion "nouvelles" si ce n'est la Programmation Objet par Prototypage (si évidemment vous venez d'un autre langage Objet par Classes).
Si on se place du point de vue de l'environnement par contre, la complexité explose avec l'environnement JS.
Ne serait-ce que se tenir à jour sur les frameworks et autres, relève du chalenge sportif :mouarf:.
Je dirais donc que c'est une question de point de vue.

Citation:

---

Angular n'est pas un framework JS.
Il y a une confusion entre AngularJS et Angular, qui lui est écrit en TS (qui monte en intérêt) et passe aussi par une étape de validation/transcompilation comme Svelte.

@RPGamer

---

Mouais, parce que Typescript ne transpile pas le code en JS ?
Tout code Typescript est converti en JS ce qui fait que tout framework Typescript est de fait un framework JS.
Même Angular Dart (DartWeb) est un framework JS, pourtant il est codé en Darlang.

Citation:

---

Si tu sais faire que de l'objet, c'est normal de le trouver complexe, vu qu'il ne s'agit pas d'un langage objet (même si un peu maintenant) mais prototypé.
Et quand on sait qu'il servait surtout pour le DOM à la base, ça avait du sens.
Le truc c'est que des « dévs back » veulent que ça fasse comme leurs langage favoris qui ne sont qu'en objet et ne veulent pas réapprendre une nouvelle logique de programmation.

Après, j'avoue que je trouve ça bien quand il s'agit de manipuler le DOM et les structures du genres, mais pour le reste c'est quand même pas facile à appréhender.

@Zefling

---

:ptdr::ptdr:
POO = Programmation Orienté Objet.
Que ce soit avec des Classes, des Prototype ou même sans (puisque ce n'est même pas un prérequis), il s'agit toujours de POO.
Après que l'on puisse trouver la POO complexe c'est une autre histoire.

Concernant les origine du JS, à la base et sans intervention de SUN (merci le marketing JAVA) il aurait ressemblé à un LISP donc dire qu'il est plus adapter à la manipulation du DOM qu'un autre langage, ...boff, boff.

Les "dévs back" justement, veulent un langage fiable et qui ne pète pas au runtime sans crier gare.
Maintenant, c'est rarement le dev qui a le dernier mot sur la stack qu'il devra utiliser et il se retrouvent souvent à devoir composer avec des choix fait par d'autres et en d'autres temps parfois.
Ça n'as donc rien à voir avec leurs "langage favoris" ou le fait de "réapprendre" quoi que ce soit.
Sans compter que je suis désolé pour vous si vous croyez réellement que JS ai introduit quelque chose de nouveau (vous semblez également croire qu'il ne s'agit pas d'un langage Objet) :ptdr:.

D'ailleurs, les "dévs front" le veulent aussi apparemment.
Qui développe en JS Vanilla quant il existe tant de langages plus sûr transpilant vers JS ?
Leurs existences même démontre à elle seule que le JS n'est pas tellement un choix mais plus une contrainte.

Citation:

---

Cette année ce sera la réécriture de l'application d'entreprise (db de 400 tables, c'est une application métier complète y compris toute la compta et hr...) d'angularjs vers react.
...

@frfancha

---

Ouf, courage l'amie :aie:
Juste par curiosité, mais 400 tables dans une DB SQL et JS pour une application métier, c'était volontaire ou c'est suite à une demande client de suicide collectif ? :ptdr:

Citation:

---

TypeScript n'est pas un langage c'est une extension de JavaScript.

@Marco46

---

Heu, ...si je prend un fichier ".ts" que je le renomme en ".js" et que je l'utilise avec un runtime js ça ne fonctionnera pas donc c'est bien un langage différent.
Il y avait le même type de discoure concernant Vala/Genie qui ne seraient pas des langages puisque transpilant vers du C/GObject.
Je regrette mais du moment que le runtime/système ne comprend pas le langage sans transpilation/compilation, c'est bien un autre langage.
Ou alors vous avez une définition de ce qu'est un langage qui m'est inconnu et tous les autres langages existants ne seraient que des vues de l'esprit.
Seule JS serait le vrai, l'unique qui dans les ténèbres les lierait tous ? :ptdr:

Citation:

---

TypeScript n'est pas un langage c'est une extension de JavaScript.

---

Citation:

---

Justement Typescript reste simplement un langage transcompilé en JS au final donc Angular (> V1) reste un framework JS...

---

Si la team Angular a décidé d'utiliser TypeScript au lieu de JavaScript c'est pas pour faire plaisir à Microsoft, c'est parce qu'écrire du code en TypeScript n'a rien à voir avec écrire du code en JavaScript. De ce fait, AngularJS n'a rien à voir avec Angular. Certe, la syntaxe est volontairement proche du JS, contrairement à ce que propose CoffeeScript par exemple, mais l'approche reste totalement différente.

Au passage, le transcompilateur TS fait beaucoup plus que d'étendre JS.

Citation:

---

Envoyé par RPGamer

Si la team Angular a décidé d'utiliser TypeScript au lieu de JavaScript c'est pas pour faire plaisir à Microsoft, c'est parce qu'écrire du code en TypeScript n'a rien à voir avec écrire du code en JavaScript. De ce fait, AngularJS n'a rien à voir avec Angular. Certe, la syntaxe est volontairement proche du JS, contrairement à ce que propose CoffeeScript par exemple, mais l'approche reste totalement différente.

Au passage, le transcompilateur TS fait beaucoup plus que d'étendre JS.

---

Angular n'a rien avoir avec angular.js => oui en effet, mais c'est juste parce que angular est différent, rien à voir avec le changement de langage. Angular aurait pu tout aussi bien être écrit en JavaScript.

Citation:

---

Envoyé par defZero

Ouf, courage l'amie :aie:
Juste par curiosité, mais 400 tables dans une DB SQL et JS pour une application métier, c'était volontaire ou c'est suite à une demande client de suicide collectif ? :ptdr:

---

La logique métier est complètement programmée dans des stored procedures SQL.
Celle présente en JavaScript ne concerne que la présentation.
Parfois certains calculs ou contrôles sont dupliqués en JavaScript pour donner un feedback instantané à l'utilisateur, mail ultimement le même calcul ou contrôle est toujours fait en SQL qui a le dernier mot.
Avant angularjs c'était des écrans lourds écrits en Visualage for Smalltalk.
Passer à angularjs est ma décision et franchement les utilisateurs sont ravis du résultat.
Alors direz vous, pourquoi changer ?
-une partie de l'application est exposée sur internet et sujette à des audit de sécurité qui exigent une version à jour du framework. Angularjs 1.7.8 reste accepté mais ce ne sera pas le cas éternellement.
-malgré notre usage de directives essentiellement (pas de controller), il n'est pas aussi simple de récupérer les composants comparé à react
-la puissance de JavaScript dans le jsx par rapport à ngrepeat, ngif est fantastique, surtout que nos tables colonnes ont des tas de metadata dans la DB qui nous permettront facilement d'automatiser une grande partie de la génération des écrans.
-afficher une table de 100 lignes en angularjs est instantané, 2000 est beaucoup moins évident. Je parle de ligne "riches" avec des composants dans les cellules. Il n'y a pas ce problème en react.
... Du moins j'espère, ce sera un des premiers tests !

Finalement, le principe même d'angularjs exige qu'il soit très permissif avec le code écrit dans l'html: a.b.c fonctionne même si a n'existe pas, ou bien a.b, ... C'est très simple et très puissant, mais un retour immédiat sur les erreurs de frappe comme en react permettra de gagner du temps au total

Citation:

---

Envoyé par RPGamer

c'est parce qu'écrire du code en TypeScript n'a rien à voir avec écrire du code en JavaScript

---

Commence par lire la documentation de TypeScript, ce que je t'explique y est écrit en gros dès la home du site de TypeScript.

Concernant la team Angular, tu confonds le choix d'aller vers une conception fortement orientée objet par classes avec le choix d'un outil qui ajoute du typage statique en ajoutant une phase de compilation.

La manière dont la team Angular utilise TS, et qui est fortement discutable, est propre à cette team. Ce n'est pas nécessairement de cette manière qu'il faut utiliser TS. Les auteurs de TS l'ont déjà expliqué à plusieurs reprises.

D'ailleurs je te ferai remarquer que de très nombreuses teams utilisent React avec TypeScript alors que la conception de React est fortement orientée prog fonctionnelle et que Vue dans sa version 3 intégrera TS out of the box (Vue est agnostique question paradigme).

Il ne restera plus rien comme petit avantage concurrentiel à Angular, d'où l'énorme gamelle qu'il se ramasse. Comme d'hab on a quelques années de retard en France sur ce sujet mais c'est la tendance lourde observée depuis 2 ans maintenant dans le reste du monde.

Perso je suis sorti d'Angular dès que j'ai pu ... Mais j'adore TypeScript ;) ... Mais malheureusement il est mal compris et encore plus mal utilisé :(

Citation:

---

Envoyé par RPGamer

Au passage, le transcompilateur TS fait beaucoup plus que d'étendre JS.

---

Il fait ce que fait Babel en supportant les dernières fonctionnalités de JS et en permettant de target une version obsolète de JS pour supporter tous les navigateurs possibles et imaginables.

Et en plus de cette feature il ajoute du typage statique.

Voilà, il ne fait rien de plus (enfin c'est déjà beaucoup :mrgreen:).

Il s'agit donc littéralement de JS + typage statique. Ça ne sert à rien d'argumenter ce n'est pas une opinion c'est un fait.

Citation:

---

Envoyé par defZero

Heu, ...si je prend un fichier ".ts" que je le renomme en ".js" et que je l'utilise avec un runtime js ça ne fonctionnera pas donc c'est bien un langage différent.

---

Si et seulement si tu utilises le système de type qui existe, faut-il le rappeler, uniquement à la phase de transpilation/compilation justement.

Inversement tu peux prendre n'importe quel fichier .js, changer l'extension en .ts et tu obtiens un code Typecript valide, c'est un des fondamentaux des design goals de TypeScript.

Si seulement vous lisiez les documentations des outils que vous utilisez :roll:

Citation:

---

Envoyé par defZero

Je regrette mais du moment que le runtime/système ne comprend pas le langage sans transpilation/compilation, c'est bien un autre langage.

Ou alors vous avez une définition de ce qu'est un langage qui m'est inconnu et tous les autres langages existants ne seraient que des vues de l'esprit.

---

Ma définition c'est de lire la documentation et lire ce qu'en disent les auteurs avant de parler à tord et à travers.

En effet une des pire erreur est d'utiliser TypeScript comme on utilise Java.

Biensûr cela ne veut pas dire jeter les patterns de conception à la poubelle, mais il faut simplifier.
Dans mon équipe j'ai mis en œuvre le passage à TypeScript pour Reactjs, il a été dur de convaincre les personnes réfractaires au typage statique,
mais ils ont vites compris l'intérêt , notamment pour la maintenance et le re-factoring.
Et contrairement aux idées reçus , écrire en TypeScript ne prends pas beaucoup plus de temps qu'écrire du JS.

Attention tout de fois à appliquer une rigeur sur la cohérence des types , car parfois on à une fausse impression de sécurité avec TypeScript.
Par exemple si vous typez un objet retourné par un service (Rest), il faut bien penser à le mettre à jour. De notre coté nous avons des packages npm pour l'accès au services, qui sont automatiquement mis à jours lors des modifications du service.

Pour en revenir au sujet React vs Angular, j'ai appris à apprécier React, le principal reproche que je lui fait c'est qu'il propose moins de chose 'in the box qu'Angular" , en gros il faut vraiment bien architecturer sa stack technique et se tenir au courant (fini les stacks qu'on met à jours une fois tout les 5ans, mais ça c'est propre au monde post 2010).

Un autre truc de chiant particulièrement avec React , c'est que des éléments présentés comme bonne pratique deviennent mauvaise pratique 6 mois plus tard. Je ne suis pas particulièrement fan de flux et du context API, parfois une simple promise sans store fait mieux l'affaire (pour un module pas trop complexe)
J'avoue que souvent ça me fais vraiment regretter .net et WPF/WinUI…

Citation:

---

Envoyé par dfiad77pro

fini les stacks qu'on met à jours une fois tout les 5ans mais ça c'est propre au monde post 2010)

---

C'est un point de vue technique.
Ce n'est pas un point de vue grosse entreprise où l'équipe de développement est là pour apporter de la valeur métier et pas du fun technologique.
Dans ce cadre si on peut convaincre d'une grosse mise à jour technique tous les 7 ans au lieu de tous les 30 ans c'est bien.
Et honnêtement une stack bien choisie tient minimum 7 ans.

Je suis dans une grosse entreprise (>15 000 employés) drivée par le métier, biensûr qu'on tempère , on ne parle pas de remplacer la stack tout les 3 ans, mais au moins de suivre les mises à jours petit à petit.

Mais comme tu le dis même si c'est plus lent dans les grosses boites, ça s'améliore nettement :)

Je préfére garder un peu de mon esprit naïf de mes débuts dans le monde pro (2011) , ça me permet de rester à jours plus facilement :mrgreen:.

Après même une stack pourris peut tenir plus de 10ans à coût de scotch (les techno "web" étant très souples), les grosses boites sont excellentes pour dissoudre les coûts de maintenance…

Citation:

---

Envoyé par Marco46

Si et seulement si tu utilises le système de type qui existe, faut-il le rappeler, uniquement à la phase de transpilation/compilation justement.

Inversement tu peux prendre n'importe quel fichier .js, changer l'extension en .ts et tu obtiens un code Typecript valide, c'est un des fondamentaux des design goals de TypeScript.

Si seulement vous lisiez les documentations des outils que vous utilisez :roll:



Ma définition c'est de lire la documentation et lire ce qu'en disent les auteurs avant de parler à tord et à travers.

---

D'après le site "TypeScript is a typed superset of JavaScript that compiles to plain JavaScript." donc non, du TypeScript n'est pas du JS puisqu'un sur-ensemble devant être compilé / transpilé.
C'est comme vouloir compiler du C++ avec un compilot C, ça ne juste marche pas.
Pourtant C++ est un sur-ensemble de C (oui, je sais il y a des incompatibilités, mais C++ est bien née comme un sur-ensemble de C).
Par contre, tout compilateur C++ doit pouvoir compiler du C sans problème 'et avec quelques flags :aie:).
C et C++ sont bien 2 langages totalement différents et il ne viendrais à l'esprit de personne de les mélanger, alors pourquoi vouloir le faire avec TypeScript et JS ?

Enfin, j'ai lu la doc et ne trouve aucune mention du fait que TypeScript ne serait pas un langage à part.
Alors je sais que tout fichier ".js" peut être renommer en ".ts" est que le compilo est assez lâche pour accepter (moyennant quelques flags), mais je n'est vue nul part où il est dit qu'un fichier ".ts" normale était compatible ".js" sans passer par la case compilation.
D'ailleurs étant donner que le compilo TS peut générer des modules JS selon les différentes norme (AMD, CommonJS, ...etc) je ne voit juste pas comment ce serait possible qu'un runtime JS comprenne le système de module natif de TS qui lui est de bien plus haut niveau.

Citation:

---

Envoyé par Marco46

Commence par lire la documentation de TypeScript, ce que je t'explique y est écrit en gros dès la home du site de TypeScript.

---

Comme le dit très justement defZero, TS est bien un superset de JS, ça signifie que ça n'est justement pas du JS, mais que tout code JS est en principe du code TS valide, c'est tout.

Citation:

---

Envoyé par frfancha

Angular n'a rien avoir avec angular.js => oui en effet, mais c'est juste parce que angular est différent, rien à voir avec le changement de langage. Angular aurait pu tout aussi bien être écrit en JavaScript.

---

Citation:

---

Envoyé par Marco46

La manière dont la team Angular utilise TS, et qui est fortement discutable, est propre à cette team. Ce n'est pas nécessairement de cette manière qu'il faut utiliser TS.

---

Les décorateurs ont été ajouté par le team TS à la demande de la team Angular précisément, marquant la fin prématurée du projet AtScript et ce qui rend sont approche complétement différente de JS d'ailleurs.

Citation:

---

Envoyé par Marco46

Il ne restera plus rien comme petit avantage concurrentiel à Angular, d'où l'énorme gamelle qu'il se ramasse.

---

Angular propose déjà tous les outils et l'architecture élégante d'une app out of the box en TS justement, c'est en ça qu'il est le seul réel framework, qui se suffit à lui-même. React n'est qu'une bibliothèque. Ils ne jouent donc pas du tout dans la même catégorie, et c'est la confusion que tu fais et qui est faite dans cet article.

Citation:

---

Envoyé par defZero

D'après le site "TypeScript is a typed superset of JavaScript that compiles to plain JavaScript." donc non, du TypeScript n'est pas du JS puisqu'un sur-ensemble devant être compilé / transpilé.

[...]

Enfin, j'ai lu la doc et ne trouve aucune mention du fait que TypeScript ne serait pas un langage à part.

---

T'es quand même capable d'écrire que TS = types + JS et quelques lignes plus loin que c'est un langage part. C'est tellement un langage à part que la team gérant TSLint a décidé de fusionner avec ESLint en y ajoutant simplement un plugin. A ce stade de mauvaise foi je ne peux plus rien pour toi.

Citation:

---

Envoyé par defZero

mais je n'est vue nul part où il est dit qu'un fichier ".ts" normale était compatible ".js" sans passer par la case compilation.

---

C'est pourtant comme ça que ça fonctionne. Si tu écris du TS sans notion de type tu n'as rien d'autre que du JS. Inutile de transpiler quoi que ce soit. Ce que fait tsc c'est d'analyser les types, de lever les erreurs, puis de transpiler en JS dans la version voulue de JS en enlevant la totalité des informations de type.

Donc concrètement si tu écris ton code en ayant comme target la version courante de JS tu verras que rien ne change entre le code TS et le code JS, tu auras juste les informations de typage en moins. C'est tout.

Citation:

---

Envoyé par defZero

D'ailleurs étant donner que le compilo TS peut générer des modules JS selon les différentes norme (AMD, CommonJS, ...etc) je ne voit juste pas comment ce serait possible qu'un runtime JS comprenne le système de module natif de TS qui lui est de bien plus haut niveau.

---

De quel mystérieux "système de module natif de TS de bien plus haut niveau" parles-tu ?

Citation:

---

Envoyé par RPGamer

Comme le dit très justement defZero, TS est bien un superset de JS, ça signifie que ça n'est justement pas du JS, mais que tout code JS est en principe du code TS valide, c'est tout.

---

C'est pas "en principe", c'est une règle. Et la seule chose qui diffère entre JS et TS c'est le système de typage.

Citation:

---

Envoyé par RPGamer

Les décorateurs ont été ajouté par le team TS à la demande de la team Angular précisément, ce qui rend sont approche complétement différente de JS d'ailleurs.

---

Les decorators sont en stage2 au TC39. Ça finira par devenir du JS vanilla. Ça arrive régulièrement qu'une feature qui n'est pas encore terminée pour JS soit intégrée en avance de phase. Dernier exemple en date l'optionnal chaining.

tsc fait aussi le boulot de Babel, c'est peut être ça qui crée la confusion dans votre esprit. Tu peux retrouver les décorateurs dans un code JS avec Babel et le plugin qui va bien. Mais tu vas peut être tenter de m'expliquer que du JS généré par Babel "n'a rien à voir" avec JS ?

Citation:

---

Envoyé par RPGamer

Angular propose déjà tous les outils et l'architecture élégante d'une app out of the box en TS justement, c'est en ça qu'il est le seul réel framework, qui se suffit à lui-même. React n'est qu'une bibliothèque. Ils ne jouent donc pas du tout dans la même catégorie, et c'est la confusion que tu fais et qui est faite dans cet article.

---

Oui l'écosystème React est un peu bordélique et il faut assembler brique par brique pour avoir l'ensemble de l'équivalent des features proposées out of the box par Angular, mais on parle de seulement 3 ou 4 briques. Pour avoir l'équivalent d'un Angular t'as besoin du core, d'un routeur, d'un state manager et basta dans 95% des cas. Et apparemment c'est cette approche qui est privilégiée par la communauté JS puisque c'est Angular qui se casse la gueule, React qui a gagné et Vue qui creuse gentiment son trou.

Après le débat framework vs lib, j'ai eu ce genre de questionnements il y a quelques années, j'en arrive à la conclusion que c'est une question sans importance parce que la communauté a tranché. Vue a pris la même approche que React, tu tires les dépendances dont tu as besoin plutôt que de te retrouver avec une usine gaz qui contient plein de choses inutiles pour toi.

Citation:

---

Et la seule chose qui diffère entre JS et TS c'est le système de typage.

---

La différence est colossale.

Citation:

---

Après le débat framework vs lib, j'ai eu ce genre de questionnements il y a quelques années, j'en arrive à la conclusion que c'est une question sans importance

---

Il n'y a pas de débat, ce sont bien deux concepts définis et différents et la question est fondamentale et globale (bien au-delà de TS ou JS). L'approche framework permet justement de tenir des projets importants de façon cohérente, auto-documentée, etc. et même si l'approche bordélique de React ou NPM s'est beaucoup développée récemment (à cause du sentiment de liberté produit par ce bordel justement), il ne s'agit que d'un effet de mode. On ne peut rien construire de pérenne et fiable sur du bordel et de la confusion. Ca rejoint l'un des premiers commentaires qui questionne où en serons-nous dans 5 ans.

Citation:

---

Et apparemment c'est cette approche qui est privilégiée par la communauté JS puisque c'est Angular qui se casse la gueule, React qui a gagné et Vue qui creuse gentiment son trou.

---

Tu continues à confondre TS et JS, framework et bibliothèque, AngularJS et Angular. Ces concepts sont totalement distincts. Ses outils ne sont pas comparables. React ne gagne rien et Angular ne se casse rien. Angular reste le framework le plus plebiscité par la communauté (notons quand même la confusion AngularJS/Angular de l'article), tout domaine de développement confondu et n'a aucun rapport avec l'abandon d'AngularJS faisant chuter son usage.

Citation:

---

tsc fait aussi le boulot de Babel, c'est peut être ça qui crée la confusion dans votre esprit. Tu peux retrouver les décorateurs dans un code JS avec Babel et le plugin qui va bien. Mais tu vas peut être tenter de m'expliquer que du JS généré par Babel "n'a rien à voir" avec JS ?

---

Pourquoi des outils et des plugins additionnels tiers alors qu'on peut l'avoir de facto? Encore du bordel en plus.

Citation:

---

Envoyé par RPGamer

La différence est colossale.

---

Elle est importante mais faut pas charrier non plus, ça n'est jamais qu'une grosse fonctionnalité en plus. En l'état c'est juste Babel + Flow, en beaucoup mieux réalisé. Mais bon, avec plusieurs types payés full time par Microsoft depuis presque 8 ans c'est pas étonnant. Et faut voir le pedigree de certains membres de la team. Ya quand même le principal concepteur de C# rien que ça.

Citation:

---

Envoyé par RPGamer

L'approche framework permet justement de tenir des projets importants de façon cohérente, auto-documentée, etc.

---

Absolument aucun rapport avec le fait d'utiliser un framework au lieu de 3 ou 4 dépendances. Et encore tu parles d'un framework pour Angular mais techniquement tu te retrouves avec autant de bordel dans ton package.json. La différence c'est surtout que Angular fait plein de choix pour toi.

Citation:

---

Envoyé par RPGamer

et même si l'approche bordélique de React ou NPM s'est beaucoup développée récemment (à cause du sentiment de liberté produit par ce bordel justement), il ne s'agit que d'un effet de mode.

---

Mais oui évidemment, 6 fois + de DL, 3 fois + de stars sur les dépôts GitHub et en tendance constante depuis 2 ans au moins (npm trends ne va pas plus loin) mais c'est une mode :aie:

Citation:

---

Envoyé par RPGamer

On ne peut rien construire de pérenne et fiable sur du bordel et de la confusion. Ca rejoint l'un des premiers commentaires qui questionne où en serons-nous dans 5 ans.

---

Question confusion et bordel Angular est champion du monde.

Citation:

---

Envoyé par RPGamer

Tu continues à confondre TS et JS, framework et bibliothèque, AngularJS et Angular. Ces concepts sont totalement distincts.

---

Pourquoi tu me parles de AngularJS ? Quand je dis que Angular se casse la gueule, je parle bien de Angular et pas de AngularJS. AngularJS est une techno morte elle est en LTS.

Quand t'as presque 70% des sondés qui te disent qu'ils ne veulent pas entendre parler de cet outil après l'avoir utilisé ou non c'est bien qu'il y a un énorme problème avec.

Citation:

---

Envoyé par RPGamer

Ses outils ne sont pas comparables. React ne gagne rien et Angular ne se casse rien. Angular reste le framework le plus plebiscité par la communauté (notons quand même la confusion AngularJS/Angular de l'article), tout domaine de développement confondu et n'a aucun rapport avec l'abandon d'AngularJS faisant chuter son usage.

---

Ah mais ça ne fait que confirmer ce que je disais dans un post précédent. Ça c'est le point de vue franco-français. Avec ses quelques années de bourre comme sur toutes les tendances. D'ailleurs c'est entrain de se retourner depuis un an environ. Je t'invite à check les offres d'emploi dans les startups françaises, c'est massivement du React et un peu de Vue. Il y a très peu d'Angular. C'est un signal faible très important pour la suite.

Pour ce qui est de la confusion AngularJS/Angular, j'ai envie de te dire la faute à qui ? C'est une des nombreuses erreurs commises sur cet outil. Un nommage pourri pour démarrer ça ne pouvait que mal se passer.

Sinon la question avait déjà été levée lors du SoJS de l'an dernier et la réponse des auteurs est claire, il s'agit de Angular, pas de AngularJS. Après si les personnes qui répondent se plantent qu'ils se plaignent à Google.

Citation:

---

Envoyé par RPGamer

Pourquoi des outils et des plugins additionnels tiers alors qu'on peut l'avoir de facto? Encore du bordel en plus.

---

Tu me dis que l'ajout des décorateurs dans TS pour Angular fait que c'est "complètement différent" pour étayer le fait que TS et JS seraient "complètement différents". Je te réponds que cette feature existe aussi pour JS en stage 2. Quel rapport avec le fait que tsc est plus simple à utiliser que Babel ?

Citation:

---

Envoyé par Marco46

Elle est importante mais faut pas charrier non plus, ça n'est jamais qu'une grosse fonctionnalité en plus. En l'état c'est juste Babel + Flow, en beaucoup mieux réalisé. Mais bon, avec plusieurs types payés full time par Microsoft depuis presque 8 ans c'est pas étonnant. Et faut voir le pedigree de certains membres de la team. Ya quand même le principal concepteur de C# rien que ça.

---

OK le typage statique est "juste" une grosse fonctionnalité d'un langage :mouarf:

Citation:

---

Envoyé par Marco46

Et encore tu parles d'un framework pour Angular mais techniquement tu te retrouves avec autant de bordel dans ton package.json.

---

Non, c'est rangé.

Citation:

---

Envoyé par Marco46

Mais oui évidemment, 6 fois + de DL, 3 fois + de stars sur les dépôts GitHub et en tendance constante depuis 2 ans au moins (npm trends ne va pas plus loin) mais c'est une mode :aie:

---

Oui, d'ailleurs des outsiders pointent le bout de leur nez en permanence. Vue.js n'est pas très vieux. Tous vont mourrir, mais c'est un problème lié à la techno et non à l'outil.

Citation:

---

Envoyé par Marco46

Question confusion et bordel Angular est champion du monde.

---

Non, il suffit de lire la doc. C'est un des principes du framework.

Citation:

---

Envoyé par Marco46

Pourquoi tu me parles de AngularJS ?

---

Car si on me lis, ce qui n'est pas ton cas visiblement, la confusion des genres et des technos faites (volontairement ou pas) dans les articles, c'est le sujet inital de mes commentaires :aie:

Citation:

---

Envoyé par Marco46

Quel rapport avec le fait que tsc est plus simple à utiliser que Babel ?

---

A quel moment je dis que c'est plus simple ou plus compliqué? Il est juste inutile avec TS. Mais aussi avec Scala.js, etc...

Je ne comprendrai jamais cet engouement pour React, sa syntaxe est totalement immonde.

Oui, JavaScript est complexe, car on lui greffe tellement de trucs et de machins pour lui faire faire des choses pour lesquelles il n'a pas été pensé à la base qu'il faut une veille technologique permanente juste pour se tenir au courant des nouvelles librairies.

Le débat prototype/classes il faut arrêter. Le prototypage est illisible, les devs de JavaScript l'ont compris en incluant les classes et les devs utilisant JavaScript l'ont compris puisqu'ils sont passés sur TypeScript.

On peut tirer d'ailleurs le chapeau à JavaScript, il parvient à être tellement mal foutu que personne n'a envie de travailler avec sans passer par un langage intermédiaire, mise à part les masochistes et les gens trop incompétents pour se rendre compte qu'ils tiennent au prototypage pour une question d'ego (Moa j'ai passé des années à maîtriser la syntaxe pourrave de JavaScript donc je vous suis séperieur) que de pragmatisme.

Citation:

---

Envoyé par Sodium

Je ne comprendrai jamais cet engouement pour React, sa syntaxe est totalement immonde.

---

Excellent, si Sodium n'aime pas c'est bon signe, content d'avoir choisi React.

Même les utilisateurs React admette pour la plupart que sa syntaxe de templating est immonde.
Après pour les puristes de JavaScript je comprends qu'une syntaxe immonde les ravissent...

Il est vrai que la syntaxe de template React est assez laide mais je ne pense pas qu'il existe de vraies puristes JavaScript. Le JS n'est qu'une contrainte liée au legacy d'un langage à script côté client, pas un choix. Le langage est bourré de bugs et de défauts que cherchent à combler de plus en plus de technos, avec le développement du Web et des natives apps sur mobile. Ainsi JS n'est plus qu'un moyen standard d'exécution du code. Probablement que JS disparaitra totalement au profit de solutions plus performantes comme un bytecode WebAssembly. Une standardisation du W3C de ce que voulait proposer Sun avec les applets Java au fond. La boucle est bouclée.

Citation:

---

Envoyé par RPGamer

Probablement que JS disparaitra totalement au profit de solutions plus performantes comme un bytecode WebAssembly.

---

Malheureusement, on ne peut toujours pas manipuler le DOM en WebAssembly. On voit émerger deux solutions pour l'instant pour un front-end wasm:

1. Créer un pont avec du code JS
2. Dessiner la GUI dans un canvas

J’espère qu'ils ajoutent la manipulation du DOM rapidement car la solution 2 n'est pas optimal, ni pour les développeurs, ni pour les utilisateurs (sauf pour des niches comme le jeux-vidéo).

JS ne disparaitra pas du jour au lendemain et WebAssembly n'est peut-être pas le candidat pour le remplacer. En revanche il est clair que les nombreux défauts de JS pourrait être supprimés, les performances augmentées et la standardisation assurée par cette approche, avec un bytecode qui puisse être produit par des langages qui transcompile déjà en JS (TypeScript, Scala, Kotlin, etc.) et exécuté au sein de navigateurs Web.

Citation:

---

Envoyé par RPGamer

Probablement que JS disparaitra totalement au profit de solutions plus performantes comme un bytecode WebAssembly.

---

J'en doute. WebAssembly n'a pas les mêmes objectifs ni la même mise en oeuvre. Il n'est pas fait pour manipuler le DOM mais au contraire il s'y intègre via du... JS. Et surtout, actuellement, WebAssembly se code en C, C++ ou Rust, donc je vois mal tous les dev frontend passer à ce genre de langage. Au contraire, la tendance est plutôt de faire du JS sur le backend.

Citation:

---

Envoyé par Sodium

mise à part les masochistes et les gens trop incompétents pour se rendre compte qu'ils tiennent au prototypage pour une question d'ego

---

Dis autrement, soi on pense comme toi, soit on est forcément un incompétent bourré d'égo.

Moi j'adore le prototypage. Et tout le monde aussi

Sauf bien sûr les incompétents incapables de penser en dehors de leurs maigres acquis, et donc incapables de remettre leurs 'certitudes' en question de temps en temps, pour sortir de leurs formatage à la POO orientée classes. :mrgreen:

Citation:

---

Envoyé par SimonDecoline

J'en doute. WebAssembly n'a pas les mêmes objectifs ni la même mise en oeuvre. Il n'est pas fait pour manipuler le DOM mais au contraire il s'y intègre via du... JS. Et surtout, actuellement, WebAssembly se code en C, C++ ou Rust, donc je vois mal tous les dev frontend passer à ce genre de langage. Au contraire, la tendance est plutôt de faire du JS sur le backend.

---

JavaScript n'a pas pour objectifs d'être exécuté sur un serveur, pourtant certains essaient de le faire. Il y aura également du front sans JS car il y a toutes les bonnes raisons pour ça.

Citation:

---

Envoyé par RPGamer

JavaScript n'a pas pour objectifs d'être exécuté sur un serveur, pourtant certains essaient de le faire.

---

En 1995, Java n'avait pas pour objectifs de faire des applis android, et pourtant... En quoi JS est moins adapté au backend, que python, ruby ou même java ? J'ai plutôt l'impression que certains y arrivent assez bien : https://www.simplytechnologies.net/b...rely-on-nodejs

Citation:

---

Envoyé par RPGamer

Il y aura également du front sans JS car il y a toutes les bonnes raisons pour ça.

---

Lesquelles par exemple ? Vu le temps qu'il a fallu pour se débarrasser de flash, je doute que JS disparaisse des navigateurs de sitôt.

Citation:

---

Envoyé par RPGamer

[...]En revanche il est clair que les nombreux défauts de JS pourrait être supprimés [...]

---

Sauf que ce que tu appelles "défauts" les fanatiques de JavaScript appellent ça des features.

Citation:

---

Envoyé par SimonDecoline

En 1995, Java n'avait pas pour objectifs de faire des applis android, et pourtant...

---

Et pour cause : Android n'existait pas. Mais sa JVM est parfaitement adapté à ce type d'usage, il a d'ailleurs été largement adopté sur mobile bien avant l'invention du smartphone car les architectures et les systèmes étaient plus divers.

Citation:

---

Envoyé par SimonDecoline

J'ai plutôt l'impression que certains y arrivent assez bien

---

Les traditionnelles liste de références sans précisions des usages sont valables pour tous types de techno. Les listes serait bien plus longues sur des technos plus matures évidemment, sans plus de signification pour autant...

Citation:

---

Envoyé par SimonDecoline

Lesquelles par exemple ?

---

Syntaxe, performances, quelques défauts, features mal ou pas implémentées, monopole historique, etc. Le développement de TypeScript et d'autres alternatives le met en lumière.

Things like the module pattern and other attempts to create private scopes with localized state and reasoning that use closures and functions wrapped in functions, wrapped in functions, are just crazy. It becomes a mess of implicit reasoning, i.e., "if you wrap a bunch of functions this way it's implied that the scope is as such and these variables belong to this part of the code, and you shouldn't touch these variables and you shouldn't call this method like this because it will break." You must read the code very carefully and follow all of the functions and closures to know the programmer's implied meaning.

Compare this to something like Java where you have explicit language elements like classes to denote local scope, methods with method scope, blocks with block scope, and access modifiers for controlling privacy. The language makes it very clear what the programmer's intent is, and it's immediately recognizable.

People argue that complaining JS doesn't have classes is a bias from using class-based, compiled OO languages, but it's not about classes. It's about clear, explicit language elements, allowing programmers to read code and quickly understand it.

On ne peut pas mieux dire :)

а по французски что это дает? Конечно, ИТ-специалисты говорят по-английски, но стараются переводить …

Je fait comme Sodium, je vous laisse traduire (russe) :mouarf: