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

Le , par Bill Fassinou

169PARTAGES

14  0 
JavaScript est un langage de programmation de scripts principalement employé dans les pages web interactives mais aussi pour les serveurs avec l'utilisation de certains frameworks JavaScript, node.js par exemple. Depuis la sortie de sa première version en 1995, il n'a cessé de gagner en popularité et en performance. Depuis 2016, trois développeurs français (Raphaël Benitte, Sacha Greif et Michael Rambeau) ont mis au point le State Of JavaScript qui est une enquête annuelle effectuée auprès des développeurs JS du monde entier afin de déterminer ce qu'ils utilisaient, ce qui leur faisait plaisir et ce qu'ils souhaitaient apprendre de plus. Le propos de cette enquête est donc de donner une vue macro des outils, frameworks et bibliothèques utilisés dans le monde année après année. Et le résultat est une collection de statistiques et d'informations qui vous aideront à vous frayer un chemin à travers l'écosystème JavaScript, selon Sacha Greif.

L'enquête de cette année recueille l'avis de près de 20 000 développeurs dans 153 pays différents à travers le monde et a été lancée en septembre dernier. Alors que les États-unis dominent l'enquête comme prévu avec 24 % des répondants, l'Allemagne et l'Australie sont toutes deux bien représentées, avec plus de 5 % des répondants chacune. L'étude s'est penchée sur les relations d'utilisation entre les différents frameworks JavaScript pour savoir par exemple le nombre d'utilisateurs de React qui utilisent également Redux, les utilisateurs de de GraphQL qui préfèrent aussi Jest ainsi de suite. La taille de chaque section du graphe ci-dessous correspond au nombre de répondants qui ont utilisé chaque bibliothèque et qui souhaiteraient l’utiliser à nouveau. Ainsi, 92 681 développeurs qui utilisent React pensent continuer à l'utiliser encore. 111 761 de ceux qui utilisent ES6 veulent toujours continuer à l'utiliser.


Le front-end reste le champ de bataille clé pour JavaScript. Une fois de plus l'espace frontal est tout au sujet React et Vue.js . Il y a deux ans, 27 % des répondants n’avaient même jamais entendu parler de Vue.js. Aujourd'hui, cette fraction n'est plus que de 1,3 %. Ainsi, alors que React occupe toujours une part beaucoup plus importante du marché, l’ascension fulgurante de Vue.js ne montre aucun signe d’arrêt et a même déjà dépassé son rival pour certains indicateurs tels que le nombre total d'étoiles GitHub. L'autre fait remarquable de ces dernières années est la chute de Angular. Bien qu'il reste très haut en termes d'utilisation brute, il affiche un taux de satisfaction relativement décevant de 41 %. Ainsi, même si sa base d’utilisateurs est considérable, il est difficile de voir comment il s'imposera face à ces grands rivaux. Svelte quant à lui gagne de plus en plus en popularité. En utilisant une nouvelle approche radicale des frameworks front-end, il a réussi à générer beaucoup d’intérêt auprès des utilisateurs.

Par le passé, les choses étaient simples. Vos données résidaient dans votre base de données, où le serveur pouvait les récupérer, les insérer dans un modèle et les envoyer au client. Mais les choses ne sont plus si simples. De nos jours, les applications doivent savoir comment récupérer les données elles-mêmes afin de restituer leurs propres modèles et composants. Cela a donné naissance à toute une gamme d'outils de récupération et de gestion de données. Redux est sans aucun doute le plus répandu de ces outils et son taux de satisfaction de 82 % témoigne de sa notoriété. Mais tout l’espace pourrait bientôt être bouleversé par l’onde de choc GraphQL. Les utilisateurs de GraphQL sont passés de 5 % à 20 % en deux ans et leur client de choix semble être Apollo. Ajoutez à cela le fait que la dernière version d'Apollo rend l'utilisation de Redux facultative, et il ne serait pas étonnant que les résultats de l'année prochaine commencent à être très différents.


JavaScript sur le back-end n'a pas connu de percée majeure ces dernières années. Alors que d'innombrables frameworks émergent chaque année, très peu parviennent à gagner suffisamment d'élan pour défier Express. Même Koa, parfois considéré comme le successeur d'Express, a un taux de satisfaction inférieur (et un nombre d'utilisations considérablement inférieur). Next.js est un entrant intéressant dans le domaine qui a suscité beaucoup d’intérêt ces derniers temps. Bien que cela ne soit pas tout à fait comparable à un back-end de nœud complet, son objectif qui consiste à résoudre le problème de rendu côté serveur pour les applications React en a fait un outil très utile. Il est également intéressant de voir quel rôle joueront les technologies sans serveur telles que AWS Lambda au cours des deux prochaines années.


Côté mobile et desktop, JavaScript a étendu sa portée bien au-delà des limites du navigateur. React Native et Electron sont les deux principales solutions pour créer des applications mobiles et de bureau utilisant les technologies Web. Ils affichent donc des chiffres similaires en termes de taux de satisfaction et de nombre d'utilisateurs. La polyvalence d’Electron (elle peut fonctionner avec n’importe quel framework d’interface utilisateur, même si elle est souvent associée à React ou Vue.js) peut expliquer le taux de satisfaction le plus élevé de la catégorie. Mais les choses sont loin d’être réglées. Airbnb a récemment publié une série complète d’articles expliquant pourquoi ils ont décidé d’abandonner React Native au profit de Native Apps.


Au lieu de React Native, les développeurs souhaitant écrire des applications multi-platesformes en JavaScript sans utiliser de modèles React peuvent également consulter Weex, qui leur permet d'utiliser l'écosystème Vue.js. Et Google a également de nombreux participants intéressants dans le domaine. Il y a Carlo (un tout nouveau framework d'application Headful Node) publié par Google et construit sur Puppeteer ; ainsi que Flutter : au lieu de créer un "pont" JavaScript comme le fait React Native, il compile en véritable code natif. Mais le code étant écrit en Dart, React Native restera donc toujours pertinent pour la plupart des développeurs JavaScript déjà familiarisés avec le système React.

« Alors que tout est actuellement calme sur le front-end, la question de savoir comment obtenir les données de la base de données au client est loin d'être résolue, et GraphQL commencera sûrement à faire de plus en plus de vagues dans ce domaine. À mesure que des solutions sur mesure GraphQL émergent à la fois pour la couche back-end et pour la couche de gestion d'état, nous pourrions bientôt sentir le sol JavaScript bouger sous nos pieds une fois de plus. Mais pour l'instant, pas de panique. Il n’y a jamais eu de meilleur moment pour devenir développeur JavaScript que maintenant, et nous sommes prêts à parier que 2019 le rendra encore plus clair », ont déclaré Sacha, Raphaël et Michael pour conclure.

Source : The State Of JavaScript 2018

Et vous ?

Qu'en pensez-vous ?

Voir aussi

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

The State Of JavaScript : participez à l'édition 2018 de l'enquête qui permet d'avoir une vue macro des technologies utilisées dans le monde JS

Mithril : un framework JavaScript moderne, simple, rapide et léger comparé à React ou Angular pour ceux qui privilégient la facilité d'intégration

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

Avatar de Marco46
Modérateur https://www.developpez.com
Le 21/11/2018 à 22:19
Citation Envoyé par Sodium Voir le message
Une recherche Google sur "well written JavaScript code" ne renvoie rien de concluant, juste des bonnes pratiques de programmation de base (nommage de variables et fonctions...).
Quand je tape "Sodium" et "cerveau", le premier résultat qu'on obtient c'est "Le Sodium : une solution efficace contre le cerveau ...".

Coïncidence ?

Trêve de plaisanteries, on a compris ton message : Tu n'aimes pas le JavaScript parce qu'il n'y a pas de typage statique natif.

Citation Envoyé par Sodium
il y a systématiquement une armée d'acharnés sectaires qui viennent hurler que l'on n'a pas compris le langage, que l'on est débile et/ou incompétent
Pour le moment c'est toi l'acharné sectaire qui vient hurler que JavaScript c'est "de la merde" pour reprendre ton argumentaire.

Si ça te saoule tant que ça qu'est ce que tu fais sur cette partie du forum et sur ce fil de discussion ? Ça fait du bien quand ça fait mal c'est ça ton truc ?
7  1 
Avatar de Krenic
Candidat au Club https://www.developpez.com
Le 21/11/2018 à 11:53
Il est assez agaçant effectivement de lire des critiques superficielles sur Javascript. Il faut savoir que contrairement aux autres langages de programmation qui ont été conçu afin de faire du développement logiciel, JS a été développé à l'époque par un simple développeur de Netscape pour créer un petit langage de script afin d'animer de façon assez sommaire les pages HTML sur le browser. Sauf que sur une page HTML, un entier ou une chaîne de caractère c'est du même au pareil, il s'est pas pris la tête avec un typage fort. voilà pourquoi JS est aussi "permissif". Est ce que c'est une bonne chose ? Peu importe la réponse à cette question parce que côté Navigateur Web Javascript a le monopole (ou plutôt avait avec les évolutions du web d'aujourd'hui).

Aujourd'hui, HTML5 a apporté de nombreuses fonctionnalités côté client avec de multiples API qui peuvent faire confondre une webapp avec une app mobile native. Les applications se sont complexifiés, il est loin le temps où l'on afichait que du texte et des images. On est dans le tout dynamique avec les SPA et les PWA. Sauf que pour construire ce genre d'applications, il faut davantage de monde et je suis assez d'accord sur la scalabilité de JS par rapport à Typescript. Sur une grosse équipe, ce manque de typage fort peut vite devenir source d'erreur et de confusion.

Donc voilà tout ce laïus pour dire que Javascript n'est pas un mauvais langage c'est juste un langage né à une autre époque où le besoin était totalement différent et personne à l'époque n'aurait pu imaginer ce qu'allait devenir le Web. S'il existe une solution c'est qu'il existe un besoin et c'est pourquoi Typescript est né. Au final, ça aide pas mal d'utiliser Typescript ça facilite la scalabilité des équipes, ça garanti un certain contrôle au moins jusqu'à la compilation, parce que oui après la transcompil on perd partie de ses bénéfices.

Quant aux framework Angular vs React, pour moi, ils ont deux visions différentes. Angular n'est pas un framework mais un ecosystème qui permet de garantir une certaine qualité de code. Angular ainsi ne fait pas que du rendu et databinding, il gère également le routing, les requêtes vers l'extérieur, la sécurité, la modularité de l'appli, l'internationalisation, et toute la stack de compil et test. Et il le fait très bien. Très bien documenté avec des exemples en Typescript ce qui aide à la montée en compétence pour des néophytes. React lui est davantage spécialisé et correspondra à un autre besoin.

Il y'a très rarement un FW ou un langage idéal qui marche partout, s'il y'a une si grande diversité c'est parce qu'il y'a une diversité de besoin.
6  4 
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 21/11/2018 à 20:13
je me demande moi pourquoi à chaque fois que l'on parle de JavaScript les détracteurs arrivent de toutes parts alors que cela n'est même pas l'objet de la news ?
Pour la 100ème fois ... parce que JS est un langage de merde. Quand une techno a autant de détracteurs, l'hypothèse la plus raisonnable est généralement qu'il y a de bonnes raisons de ne pas aimer cette techno.
Il est difficile d'être développeur web sans avoir du à un moment où l'autre acquérir une certaine expérience de JS. Partir du principe que tous ses détracteurs le critiquent à cause d'une méconnaissance est donc une très lourde erreur.

Perso quand même là où je me gausse c'est quand je lis de ta part
Quand on critique les propos d'une personne, le minimum est d'amener un minimum d'arguments ou d'expliquer au moins ce que l'on critique.
Est-ce que tu te "gausses" parce que du code TypeScript est forcément retranscrit en JavaScript (bien dégueulasse) ? Si tu pars par là, tout code finit par être transformé en binaire, donc peut-être que l'on devrait tous coder en binaire (ou au moins en assembleur) ?
6  5 
Avatar de Sodium
Membre extrêmement actif https://www.developpez.com
Le 22/11/2018 à 19:21
C'est illisible parce que tu n'y comprends rien. De même que le japonais ou le russe te paraitrais illisible. Tu es juste incompétent et borné au possible, c'est tout.
Bref, ça gueule, ça insulte ... et personne n'a toujours pas été foutu de me trouver un exemple de beau code en JavaScript

Je n'aurai peut-être convaincu personne mais j'aurai au moins bien rigolé devant votre mauvaise foi affligeante, ainsi que l'incompétence de nombreux intervenants qui essayent de donner des leçons en mélangeant des concepts basiques de programmations

Citation Envoyé par Pyramidev Voir le message
...
Tu expliques limpidement ce qu'essayait de démontrer l'auteur du blog cité plus haut que j'avais lu un peu en diagonale car l'auteur a tendance à être extrémiste en hurlant "telle pratique c'est le MAL et il ne faut JAMAIS le faire !"
5  3 
Avatar de NoSmoking
Modérateur https://www.developpez.com
Le 21/11/2018 à 19:01
Bonjour,
Citation Envoyé par Sodium
Je ne comprends même pas pourquoi il y a des gens prêts à perdre du temps à venir effectuer une levée de bouclier dès que l'on critique JavaScript (c'est à dire plus ou moins chaque fois que l'on aborde le sujet ...
je me demande moi pourquoi à chaque fois que l'on parle de JavaScript les détracteurs arrivent de toutes parts alors que cela n'est même pas l'objet de la news ?

Perso quand même là où je me gausse c'est quand je lis de ta part
Citation Envoyé par Sodium
C'est ce que j'ai fait : je n'utilise plus JS que ce pour quoi il a été conçu : ajouter des interractions simples sur une page web.
Si je veux faire une application complexe j'utilise Angular.
4  1 
Avatar de nhugodot
Membre régulier https://www.developpez.com
Le 21/11/2018 à 23:44
Pour info, le créateur de JS, Brendan Eich, avait voulu prendre Scheme, un des deux LISP de l'époque, pour langage de script pour navigateur... Sa hiérarchie lui a demandé de prendre/pondre au contraire un langage de script proche de la syntaxe ultra habituelle de C/C++/Java, choix marketing mais pas des plus heureux, et lui a même imposé de le nommer JavaScript pour coller à Java... Le monde en eut été totalement autrement, si le choix de Eich, Scheme, avait été réalisé, avec un langage solide, extensible (macros) par nature, et surtout fonctionnel! On aurait pas perdu 20 ans et plus (les FP revenant enfin)..., autant de trous de sécurité, le parallélisme (CPU ARM multicores sur nos smartphones), etc. Sic!

"JavaScript est une merde": j'acquiesce non parce que ça l'est (et ça l'est...) mais parce que ça a détourné le monde des dev de vrais langages beaucoup, beaucoup mieux pensés, académiques, propres, puissants, lisibles, etc. Que SmallTalk et Lisp aient eu si peu de succès est triste... Mais le monde est rempli de succès de bricolages (de génies), à commencer par le PC et DOS/Windows... Et que même Linux, initié par un jeune étudiant et non pas une vraie organisation solide, ai tué les Unix et NT me laisse pantois sur cette industrie: bordel ou génie, ou les deux...

Pour revenir au sujet, après avoir tâté divers frameworks avec mes collègues, la messe est dite: chacun a ses forces et faiblesses, et mieux vaut fouiner la faiblesse que la force, et trouver là où le bat blessera: pour le mobile, je ne parie plus que sur React Native tant nous nous sommes cassé les dents sur les autres frameworks sur une fonctionnalité ou une autre, telle que les badges de notification pour une app iOS par exemple, ce que d'autres FW faisaient mal ou pas. Sans parler des motifs interactives, etc.: là, seul un FW vraiment mature ayant essuyé TOUS les plâtres récents (upgrade d'iOS, pour ne pas le nommer, Apple se foutant vraiment bien des dev hors de ceux qui ont mangé leur pomme...) est fiable. Et je connais nombre d'agences web, en France ou ailleurs, qui me l'ont aussi dit, après avoir testé d'autres FW pour le mobile...

(Cela dit, si j'avais le choix, sur seulement mobile, je prendrais Dart/Flutter... plus de JS ou TS ou... ni d'API native à binder, tout se fait dans Flutter même les composants graphiques, et c'est compilé, bref, c'est propre, loin de ces bricolages aussi géniaux soient-ils... mais ce n'est pas le sujet ici, pardon.)

Hors mobile, juste sur Web desktop, React vs Angular, c'est "le bazar vs la cathédrale" (voir ce que ça signifie sur wikipédia, instructif) , c'est "petite équipe stable" (agence web, start-up) versus "grande entreprise et équipe mouvante", de l'avis d'experts et formateurs sur les deux: Angular, en imposant ses choix et en étant très complet, permet à des nouveaux venus d'autres entreprises où ils l'utilisaient d'arriver en terrain connu et très balisé, d'être opérationnel rapidement. React permet trop de choix d'outils de son écosystème à la demande, mais inversement permet aussi de choisir ce qu'on veut selon le besoin.

Tout ça me fait penser aux OS, les distros GNU/Linux (comparables à la demande pour coller au plus près du besoin, optimales) vs Windows ("je fais tout pareil, partout, je suis gros mais facile, c'est pareil partout"...), non?

Vive WASM, j'attends que Python y passe... enfin quelque chose de lisible... (oups, ok, troll inside, je sors...)

ps:regardez ReactXP de Microsoft avec lequel ils ont fait leur Skype, et les initiatives équivalentes React Native for Web et React DOM (et https://platform.uno), ça serait cocasse que ce soient les langages mobile natifs qui aillent sur le Web grâce à WASM, et tuent JS, in fine, plutôt que le contraire comme avec React Native, non?
4  1 
Avatar de blbird
Membre éprouvé https://www.developpez.com
Le 22/11/2018 à 14:51
Javascript est un excellent langage. Il suffit de s'y intéresser un peu, de ne pas être bloqué comme beaucoup sur le langage actuel qu'on vénère (Java, C#, Php, Python, C/C++ ou autre).

Chaque langage a ses avantages et ses inconvénients.

Mais on ne peut pas laisser dire que JS est un mauvais langage parce que :
  • il n'est pas multithread : on voit bien NodeJS monothread qui a éclaté en perf (surtout en montée en charge...!!) d'autres serveurs web très connus et utilisés. Le créateur de NodeJS l'explique très bien d'ailleurs ici :
  • il n'y a pas de typage fort : ici on est dans le cadre des capacités des développeurs à définir des contrats et à les respecter sans qu'on leur tienne la main, rien d'autre
  • il n'y a pas de POO : JS est en POP, qui, une fois qu'on l'a compris, est tout aussi intéressant (voir plus pour moi) que la POO


Les exemples d'applications grands publics ayant un succès phénoménale existent bien :

  • Discord : 50 MILLIONS de users toute plateforme confondue, 90% de code identique sur toutes les platesformes : Web, PC, Linux, Mobiles
  • Visual Studio Code : un excellent éditeur
  • Beaucoup des sites webs les plus utilisés


Bref, comme souvent, les détracteurs d'un langage communément utilisé n'ont tout simplement pas compris l'intérêt du langage et encore moins ses principes et son fonctionnement. Ils s'arrêtent à la comparaison de leur langage ou concepts favoris, sans chercher à sortir de leur zone de confort. Triste.
4  3 
Avatar de blbird
Membre éprouvé https://www.developpez.com
Le 22/11/2018 à 16:49
Citation Envoyé par Sodium Voir le message
Je ne vois pas bien le rapport, on peut très bien faire de la composition en PHP ...
https://r.je/you-do-not-need-inheritance-oop.html
Bref, encore une preuve d'ignorance.
Arrête de traiter les autres d'ignorants quand tu affiches la tienne à longueur de réponses. Ce qui fait toute la différence, que tu n'as absolument pas comprise du tout, c'est que JS fait du prototypage dynamique directement dans le langage de base. Tout JS est basé là-dessus, comme le C# ou le Java sont basés eux sur le principes de classes et d'héritage. Et ton article va même clairement dans le sens de Javascript : il explique très bien que l'héritage est toujours plus mauvais que la composition. Ca tombe bien, JS est basé sur la composition dynamique : tu peux ajouter des comportements à la volée à tout instance de prototype (un objet en JS) quand tu en as envie. Bon courage pour faire pareil en POO dynamiquement, même avec les interface, sans toucher au code de tous les objets.

L'héritage, c'est quand tu définis les objets par rapport à ce qu'ils sont, la composition c'est définir les objets par rapport à ce qu'ils font. Et le JS excelle en composition, car c'est le fondement même du langage, bien plus que le design pattern Composition associé à un langage POO... Ca n'a juste rien à voir.

Citation Envoyé par Sodium Voir le message
De la même manière que des mecs ont érigé des temples et des pyramides majestueux il y a 5000 ans avec des rondins.
On peut faire n'importe quoi avec n'importe quoi à condition d'y consacrer suffisamment d'efforts. On le fera juste moins vite et bien. Si tu aimes travailler avec des rondins tant mieux pour, perso je préfère utiliser une grue...
Ah ouais. Mais le mec qui sait conduire une grue, il comprend tout l'intérêt que ca a comparé aux rondins à la main. Par contre le mec qui est infoutu d'apprendre à conduire la grue, il passe son temps à la dénigrer car c'est trop compliqué à utiliser. Ca te rappelle quelqu'un?

Citation Envoyé par Sodium Voir le message
C'est illisible parce que c'est illisible. Quand je lis du code, je ne devrais pas avoir à filtrer visuellement près de 3/4 d'éléments inutiles pour comprendre la logique.
C'est illisible parce que tu n'y comprends rien. De même que le japonais ou le russe te paraitrais illisible. Tu es juste incompétent et borné au possible, c'est tout.

Peut-on revenir au sujet plutôt que de subir ce troll?

Perso, VueJS est pour moi clairement plus sympa qu'Angular ou React. J'aime beaucoup la composition de composants, et la facilité d'apprentissage, la librairie minimaliste et la documentation extrêmement claire. Je suis content qu'il se développe.

Grâce à cet article, j'ai découvert GRAPHQL : j'adore, tout simplement. A découvrir absolument!
4  4 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 22/11/2018 à 18:28
Citation Envoyé par blbird Voir le message
il explique très bien que l'héritage est toujours plus mauvais que la composition. Ca tombe bien, JS est basé sur la composition dynamique : tu peux ajouter des comportements à la volée à tout instance de prototype (un objet en JS) quand tu en as envie. Bon courage pour faire pareil en POO dynamiquement, même avec les interface, sans toucher au code de tous les objets.

L'héritage, c'est quand tu définis les objets par rapport à ce qu'ils sont, la composition c'est définir les objets par rapport à ce qu'ils font. Et le JS excelle en composition, car c'est le fondement même du langage, bien plus que le design pattern Composition associé à un langage POO... Ca n'a juste rien à voir.
Ajouter des comportements à la volée à une instance de prototype, ce n'est pas de la composition au sens orienté objet.
Tu sembles ne pas avoir compris les intérêts de la composition en POO.

Par exemple, admettons qu'on ait une classe X d'une bibliothèque externe, par exemple une classe pour loguer, ou bien un classe pour envoyer des courriels, ou bien une classe pour interagir avec une base de données.
Admettons qu'un programme contienne une classe Y qui encapsule X. Y est la seule classe du programme qui connaît X et n'offre pas toutes les fonctionnalités de X. Elle n'a que le strict nécessaire dont le programme a besoin.

Un jour, on se rend compte qu'il existe une bibliothèque externe Z qui semble meilleure que X sur plusieurs points. Peut-on remplacer X par Z dans le programme ?

Avec l'architecture ci-dessus, il n'y a besoin de n'analyser qu'une seule classe du programme (Y) pour savoir quelles fonctionnalités de X sont utilisées. Et si on décide de faire le changement, même si toutes les méthodes de Z ont des signatures complètement différentes de celles de X, cela ne pose pas de problème : il n'y a qu'une seule classe du programme à mettre à jour : Y.

Cette flexibilité est possible, car Y n'est pas une extension de X. Y a ses propres méthodes, avec leurs propres signatures. En outre, Y a volontairement moins de fonctionnalités que X.

Pour qu'un gros programme soit bien structuré et maintenable, il faut forcément beaucoup d'encapsulation, un peu partout.

L'héritage, lui, a d'autres buts. Il sert surtout à faire du polymorphisme.

Quand on dit qu'il faut généralement préférer la composition à l'héritage, c'est surtout parce que les débutants ont tendance à ne pas encapsuler. Dans mon exemple, un développeur mauvais en POO aurait fait une classe Y qui dérive de X pour y ajouter les méthodes qui l'intéressent car, à court terme, c'est plus rapide d'étendre à l'arrache les fonctionnalités d'une classe existante que de faire de l'encapsulation.
4  1 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 20/11/2018 à 14:30
Citation Envoyé par Sodium Voir le message

Tout l'intérêt d'Angular est justement de ne plus avoir à faire du JavaScript mais du TypeScript, langage qui permet enfin de faire du "JavaScript" proprement.
Ça n'a absolument aucun rapport avec Angular tu peux faire du TypeScript avec n'importe quelle librairie ou framework, c'est un superset pas un langage de remplacement. TypeScript se porte très bien et a manifestement gagné la bataille des outils de typage statique en écrasant Flow.

Angular comporte trop d'incohérences, de lourdeurs, et de fonctionnalités inutiles comme ses systèmes de modules et d'injection de dépendances qui font doublons avec les fonctionnalités natives de JavaScript.

Citation Envoyé par Sodium Voir le message

La chute d'Angular montre bien que l'écosystème JavaScript attire principalement des développeurs amateurs et peu exigeants en termes de qualité de code.
C'est tout le contraire, l'adoption forte de Angular malgré le fait qu'un développeur sur trois (et il y a une majorité de développeurs confirmés et seniors qui ont répondus à cette enquête) le trouve mauvais s'explique parce que dans un grand nombre de DSI des personnels incompétents sur ces sujets (chefs en tout genre, architectes, etc...) font des choix techniques sans rien y comprendre sur la seule foi que c'est Google qui est derrière.

Citation Envoyé par Sodium Voir le message

Après y avoir goûté, je me vois mal revenir à du simple JavaScript sans typage fort et sans véritables classes.
C'est parce que tu n'as jamais pris la peine d'apprendre le JavaScript moderne. Les classes ne sont utiles que pour structurer un modèle, elles sont totalement inutiles pour structurer la logique de ton application puisque les fonctions sont first-class et que tu as les modules (CommonJS ou ES6 selon ta préférence ou tes contraintes).
3  1 
Contacter le responsable de la rubrique Accueil

Partenaire : Hébergement Web