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 !

É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 »

Le , par Bill Fassinou
102 commentaires

314PARTAGES

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


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.


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.


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 ?

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

Voir aussi

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

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

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

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

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

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

102 commentaires
Commenter Signaler un problème
Avatar de
https://www.developpez.com
Le 01/01/2020 à 17:27
Citation Envoyé par Sodium Voir le message
L'article en question est factuel point par point, avec des exemples concrets et ne contient pas grand-chose qui puisse être attaquable.

Non pas du tout, c'est un ramassi d'inepties et d'arguments fallacieux. Déjà l'article est publié sur le blog "JavaScript Non Grata, Just say no to this abomination" par un fanboy de Smalltalk. Autant dire que niveau impartialité on va être servi...

Point 1 : JS n'a pas de type entier. Et alors ? Les flottants ne sont pas suffisants ? Bash ne gère pas les flottants de base, et c'est bien plus génant. Le C gère des entiers et des flottants : résultat quand on travaille avec des entiers les comparaisons ne posent pas de problème mais il faut faire attention lors des divisions, mais avec les flottants c'est l'inverse, mais parfois il y a des conversions implicites, et le type int peut être 32 bits ou 64 bits selon l'architecture... c'est effectivement beaucoup mieux que JS...

Point 2 : typage faible et conversions automatiques. Ce sont des choix de conception dont je ne suis pas fan personnellement mais qui se retrouvent dans pas mal de langages dynamiques. Une bonne partie des exemples est assez discutable voire franchement malhonnête. Je vous conseille l'exemple de "arr" qui mérite à lui seul l'oscar de la mauvaise foi.

Point 3 : ajout automatique du ";". Ok, un débutant fera l'erreur une fois dans sa vie, et ensuite ? En Python aussi il faut faire attention au découpage des lignes... et également à l'indentation. Et à peu près tous les langages ont leurs pièges de syntaxe.

Point 4 : JS est mal utilisé, "Much of the code in the wild, especially those in commonly used libraries, are very badly written". D'où vient cette affirmation ? Quelles sont ces libs ? Des stats d'utilisation ? Des rapports d'analyse de code ? Non, il faut croire l'auteur sur parole et admettre que c'est la faute de JS. Avec un autre langage on n'aurait certainement que du code propre et même l'ado qui se prend pour un codeur 2h après avoir découvert la console de son navigateur produirait magiquement du code parfait...

Point 5 : JS dépend fortement des variables globales. Et alors ? Les variables globales sont déconseillées dans quasiment tous les langages. Le C possède encore "goto" mais quasiment personne ne l'utilise pour autant; qu'il soit bien implémenté ou pas tout le monde s'en fout.

Point 6 : " JavaScript code can fail silently due to syntactical slip-ups. It has happened to me several times, and tracking down the reason can be most exasperating." Encore des détails de syntaxe mais cette fois on ne sait même pas lesquels. Mais on peut croire l'auteur sur parole car ça lui est arrivé plusieurs fois et c'était exaspérant...

Point 7 : les prototypes ne conviennent pas pour des grosses applications. Pas d'argument ni de source concrète. L'auteur étant un fan de Smalltalk, on ne doute pas de l'objectivité de son analyse... Il arrive même à citer C++ comme exemple de langage objet; mais il ne parle pas de l'héritage de classes en diamant ni de la gestion des exceptions levées dans un destructeur... étonnant...

Point 8 : la programmation asynchrone est compliquée en JS. Ben c'est surtout la programmation asynchrone en général qui est compliquée et comme JS est l'un des rares langages mainstream à l'utiliser autant alors forcément... En fait, la critique porte essentiellement sur la syntaxe et n'a plus vraiment lieu avec les promise et les async/await.

Point 9 : JS n'est pas comme Lisp. Et pour cause, JS a été inspiré par Scheme et non Lisp. Et apparemment c'est suffisamment bien fait pour que certains cours d'algorithmie migrent de Scheme à JS: https://en.wikipedia.org/wiki/Struct...ipt_Adaptation

Point 10 : le seul avantage de JS tient dans des frameworks comme Node.js et AngularJS. Bon là c'est carrément du délire, l'auteur a complètement craqué. Admirez : "Everyone understood that JavaScript was a terrible language, and so it was used only sparingly. But then, someone thought it was a good idea to put this awful language on the server."

"factuel point par point, avec des exemples concrets et ne contient pas grand-chose qui puisse être attaquable"...
14  4 
Pyramidev
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 01/01/2020 à 13:57
Citation Envoyé par melka one Voir le message
setTimeout qui servait a faire le l'asynchrone pour faire bien on a ajouter les promise et comme sa suffisait pas on a rajouter async await.
Quand le code est dégueulasse, c'est bien que le langage évolue pour rendre le code plus lisible. Je vais copier-coller des codes de l'article Asynchronous JavaScript: From Callback Hell to Async and Await
 que j'aime bien citer.

Code dégueulasse avec le continuation-passing style :
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
const verifyUser = function(username, password, callback){
   dataBase.verifyUser(username, password, (error, userInfo) => {
       if (error) {
           callback(error)
       }else{
           dataBase.getRoles(username, (error, roles) => {
               if (error){
                   callback(error)
               }else {
                   dataBase.logAccess(username, (error) => {
                       if (error){
                           callback(error);
                       }else{
                           callback(null, userInfo, roles);
                       }
                   })
               }
           })
       }
   })
};
Code moins dégueulasse avec les promesses :
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
11
const verifyUser = function(username, password) {
   database.verifyUser(username, password)
       .then(userInfo => dataBase.getRoles(userInfo))
       .then(rolesInfo => dataBase.logAccess(rolesInfo))
       .then(finalResult => {
           //do whatever the 'callback' would do
       })
       .catch((err) => {
           //do whatever the error handler needs
       });
};
Code lisible avec async et await :
Code : Sélectionner tout 
1
2
3
4
5
6
7
8
9
10
const verifyUser = async function(username, password){
   try {
       const userInfo = await dataBase.verifyUser(username, password);
       const rolesInfo = await dataBase.getRoles(userInfo);
       const logStatus = await dataBase.logAccess(userInfo);
       return userInfo;
   }catch (e){
       //handle errors as needed
   }
};
Le code souffre toujours du problème décrit dans l'article What Color is Your Function? mais, au moins, par rapport au continuation-passing style, il y a eu du progrès.
6  0 
defZero
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 29/12/2019 à 0:31
Pensez-vous que JavaScript soit un langage complexe ? Pourquoi ?

Ça dépend d'où vous placer le curseur de la complexité .
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 .
Je dirais donc que c'est une question de point de vue.

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.

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

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

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.

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
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 ?

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 ?
6  1 
Avatar de
https://www.developpez.com
Le 01/01/2020 à 19:23
Citation Envoyé par Sodium Voir le message
En voilà un joli démontage partial en règle rappelant l'analyse des discours scientifique par des climatosceptiques
C'est tout ? Je suis déçu : tu ne m'as même pas accusé d'être responsable aussi de l'Holocauste et de l'assassinat de Kennedy, pour mieux prouver, de façon factuelle, que JS c'est de la merde.
7  2 
Marco46
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 29/12/2019 à 11:03
Citation Envoyé par RPGamer Voir le message
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 Voir le message
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 ).

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.
6  2 
frfancha
Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 30/12/2019 à 11:42
Citation Envoyé par Sodium Voir le message
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.
5  1 
Jitou
Avatar de Jitou
Membre confirmé https://www.developpez.com
Le 01/01/2020 à 11:17
Je suis surpris que la côte d'Angular dégringole à ce point !

C'est que c'est un framework exigeant qui demande beaucoup de temps et d'efforts avant de commencer à travailler avec. J'ai d'ailleurs renoncé à l'imposer au sein de mon équipe pour ne pas gréver le projet, on est plutôt parti sur une solution bateau : Spring Java + Thymeleaf + Bootstrap + JQuery. Le projet terminé on ne regrette pas ce choix car tous le monde s'y est senti très à l'aise dès le départ et dans ce cas de figure c'est le prinicpal. Après même si les autres frameworks JS sont plus intéressants sur le papier il manquera toujour les nombreuses bibliothèques de composants dédiés de qualité pro dont Angular est richement doté et ça celà n'a pas de prix lorsqu'on developpe pour les entreprises.
4  0 
Marco46
Avatar de Marco46
Expert éminent sénior https://www.developpez.com
Le 29/12/2019 à 11:11
Citation Envoyé par defZero Voir le message

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

Citation Envoyé par defZero Voir le message

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.
4  1 
dfiad77pro
Avatar de dfiad77pro
Membre chevronné https://www.developpez.com
Le 29/12/2019 à 11:28
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…
3  0 
frfancha
Avatar de frfancha
Membre éprouvé https://www.developpez.com
Le 29/12/2019 à 15:11
Citation Envoyé par dfiad77pro Voir le message
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.
3  0 
Commenter Signaler un problème