Et si JavaScript allait droit dans le mur ?

Posté par Bruno Michel (site web personnel) le 04 mars 2016 à 15:59. Édité par Davy Defaud, Pierre Jarillon et patrick_g. Modéré par patrick_g. Licence CC By‑SA.

Étiquettes :

mar.

2016

Cette dépêche pose la question de l’avenir du JavaScript. Celui‐-ci continue de gagner en popularité, mais aussi en complexité. L’auteur du journal a étudié d’autres langages encore peu connus (Elixir, Elm, Pony, Oden et Crystal) et ceux‐ci lui ont fait sauter aux yeux les défauts du JavaScript. Il s’interroge donc sur le futur de ce langage.

Dans les commentaires du journal, de nombreux développeurs ont fait un retour sur leur expérience. Certains apprécient le JavaScript (souvent, un sous‐ensemble de ce langage qui va à l’encontre des dernières nouveautés). D’autres, souhaiteraient fortement s’en débarrasser, mais quasiment tous sont d’accord sur le fait qu’il va rester grâce à son monopole sur les navigateurs).

Certains ont encouragé à essayer leur langage de prédilection : Go, OCaml, ClojureScript, etc.

Enfin, on peut également retrouver un certain espoir avec WebAssembly (le successeur d’asm.js), qui permettrait à de nombreux langages d’être compilés vers la plate‐forme Web.

Always bet on JS — Brendan Eich

Je me pose pas mal de questions sur l’avenir du JavaScript. D’un côté, il semble plus fort que jamais et ses surcouches (CoffeeScript, PureScript, etc.) ne sont plus à la mode. De l’autre, ses défauts me sautent de plus en plus aux yeux.

Je passe pas mal de temps à regarder de nouveaux langages de programmation. La plupart resteront expérimentaux, mais de temps à autre, un langage perce. Ce fut par exemple le cas de Go, il y a quelques années. Ceci dit, ma motivation principale quand j’étudie ces nouveaux langages n’est pas tant de trouver le futur langage qui deviendra à la mode que d’apprendre de nouvelles façons de penser et de programmer. Voici un petit tour très très succinct des derniers langages qui ont retenu mon attention :

Crystal est un langage dont la syntaxe s’inspire très fortement du Ruby, mais qui est compilé et non pas interprété. Cela lui donne des performances bien plus avantageuses et offre le filet de sécurité qu’est le typage statique (sans avoir à ne jamais écrire le moindre type !) ;
Pony est un langage orienté objets, avec un modèle d’actors (similaire à celui d’Erlang ou Akka) et un système de capacités (capabilities) très intéressant. La syntaxe est très agréable et on retrouve de nombreuses structures tirées des langages fonctionnels (pattern matching, application partielle d’une fonction) ;
Oden est un langage qui vise à profiter de l’écosystème golang, mais avec un langage plus fonctionnel. On retrouve ainsi du typage statique, avec la prise en charge du polymorphisme, ainsi qu’une syntaxe plus épurée que le Go ;
Elm est un langage fonctionnel pour écrire des applications dans un navigateur. Prenez React, Redux, Immutuable.js, enlevez beaucoup de bruit pour ne garder que l’essentiel, poussez le concept un peu plus loin, et Elm pourrait bien être ce que vous obtenez ;
Elixir est déjà plus établi que les langages précédents. C’est un langage qui permet de profiter de la machinerie d’Erlang quand on est allergique à sa syntaxe. Au passage, on gagne aussi des outils bien pratiques.

Bien sûr, il y aurait beaucoup plus à dire sur chacun de ses langages, mais ce qui m’intéresse ici est qu’ils apportent beaucoup de mécanismes qui me manquent cruellement quand je code en JavaScript.

L’asynchrone

JavaScript, avec son Event Loop et ses callbacks dans tous les sens, était à la pointe de la gestion de l’asynchrone il y a quinze ou vingt ans. Maintenant, CSP est devenu populaire, et à juste titre.

JavaScript n’est pas resté immobile. On a vu apparaître les Promise, puis certains ont détourné les générateurs. On parle beaucoup d’async/await. Il n’empêche, on est toujours dans un bourbier, coincé entre des API qui utilisent parfois des callbacks, parfois des promises.

Async/await est présenté comme une solution miracle depuis un bout de temps mais n’avance que très lentement. Il n’a pas été intégré à ES6, il ne passera pas dans ES2016 et ça semble mal parti pour ES2017. Et pour cause, aucun moteur JavaScript des principaux navigateur n’a d’implémentation pour lui. Côté Node.js, pas mieux, on attend sur V8 et il n’y aura pas de version LTS qui prendra en charge async/await avant un paquet de temps. On peut jouer avec Babel en attendant, mais ça reste un jeu, pas quelque chose que l’on peut espérer utiliser en production et encore moins dans un projet libre.

La confiance dans le code

La confiance dans le code passe naturellement par les tests. Mais ceux‐ci ne sont pas parfaits et ne devraient en aucun cas être notre seul moyen d’avoir confiance dans le code que l’on écrit. D’ailleurs, les autres langages précédemment cités sont très riches en enseignements de ce côté‐là.

Il y a bien sûr l’immutabilité (on ne modifie jamais un objet ou une valeur, on en crée un nouveau avec les informations mises à jour). Côté JS, const permet juste d’éviter de réassigner une valeur à une variable, mais si cette valeur est un objet ou un tableau, il est toujours possible de le modifier. On a également Object.freeze et Object.seal, mais, franchement, vous avez déjà vu des gens recommander d’utiliser ça à une large échelle ? Non, c’est trop compliqué en pratique, surtout quand on utilise des dépendances externes.

Le typage statique est également très intéressant pour détecter des erreurs. Et Elm en fait un usage très instructif : non seulement, il détecte les erreurs, mais il explique pourquoi et permet d’apprendre certaines subtilités du langage (parfois, on gagne juste un temps fou en détectant une typo).

Ici, l’héritage du JavaScript pèse lourd dans la balance. Il y a trop de pièges, trop de comportements qui demandent une attention permanente (perdre le this, se tromper dans la portée d’une variable).

Les outils

J’en ai parlé au‐dessus : le compilateur d’Elm fait des merveilles. Elixir a également des outils très solides. Plusieurs des langages ci‐dessus ont des fmt, à la manière de gofmt, pour formater le code d’une manière standard. Je ne suis pas un utilisateur d’EDI, mon Neovim me convient bien, mais ça ne veut pas dire que je refuse l’aide d’outils pour m’aider dans mes activités de codage.

Et là encore, JavaScript est à la traîne. Oh, il ne manque pas d’outils ! C’est même l’inverse, on croule sous les gulp, grunt, broccoli, brunch, webpack, browserify, rollup, babel, estlint, jslint, jscs, jshint, etc. Et on s’y perd. D’un projet à l’autre, ce n’est jamais la même chose, jamais les mêmes règles pour le lint. Un coup, ce sont des require CommonJS, l’autre des import/export d’ES6. Et je ne parle même pas du temps fou qu’il faut passer pour réussir à les compiler. Et quand vous avez un outil qui marche, vous pouvez être sûr que dans quelques mois, ses greffons pour faire du Sass ou générer des sprites ne seront plus maintenus. Ce n’est pas pour rien que l’expression JavaScript fatigue est très à la mode.

Un écosystème verdoyant

On parle souvent du nombre impressionnant de paquets publiés sur npmjs.com. Pourtant, quand on y regarde de plus près, c’est loin d’être reluisant. On trouve des tonnes de paquets qui sont des expérimentations qui n’ont jamais dépassé le stade de la version 0.0.x. Ensuite, il y a tous ces greffons d’intégration d’un outil avec l’autre (sails-generate-backend-gulp-webpack pour donner un exemple du ridicule que l’on atteint).

La bibliothèque standard de JavaScript me désole toujours autant. Il y a bien lodash, mais, franchement, j’aimerais bien avoir pick ou debounce dans la bibliothèque standard.

Node.js ne fait pas mieux. Il faut toujours installer un paquet pour faire un mkdir -p, ou un rm -rf (d’ailleurs, vous risquez de vous retrouver avec rimraf et del si vous ne faites pas attention).

Enfin, certaines entreprises ont les dents longues et il n’est pas rare d’en venir aux « drames » pour parfois faire avancer les choses. On se rappelle du fork io.js pour soustraire Node.js de l’emprise de Joyent. Plus récemment, c’est le principal contributeur d’express qui a jeté l’éponge (et même deux fois) pour des raisons similaires. On peut aussi s’amuser de GitHub transformé en bac à sable. Mais, ce qui est sûr, c’est qu’il y a bien des progrès à faire dans ce domaine.

La complexité du langage

Dernier point, avec ES6 et les versions futures, je trouve le langage de plus en plus complexe. Mais surtout cette complexité ne répond pas à mes besoins. C’est sûrement très bien d’avoir des décorateurs des observables et des symboles. Mais je trouve déjà les styles de code JavaScript très disparates et je ne pense pas qu’ajouter de nouvelles fonctionnalités comme celles‐ci apportent vraiment quelque chose de suffisamment intéressant pour compenser la complexité induite.

Au final, je suis de plus en plus déçu. Il y a sûrement certains points qui me sont personnels et d’autres qui sont partagés par la communauté. En tout cas, je vois cela comme une grosse faiblesse du JavaScript, et comme je ne vois pas les choses changer dans les prochains mois ou années, j’ai l’impression que le JavaScript va droit dans le mur. Je vais bien sûr continuer à utiliser du JavaScript au quotidien. Sa place dans les navigateurs en fait quelque chose de trop difficile à éviter. Mais je vais aussi continuer à regarder ce qui se fait ailleurs et probablement finir par détester le JavaScript.

Et vous, quels sont vos langages du moment ? Et que font‐ils mieux que JavaScript ?

Aller plus loin

Journal à l’origine de la dépêche (498 clics)
Crystal (239 clics)
Pony (233 clics)
Oden (214 clics)
Elm (265 clics)
Elixir (337 clics)

# Changement en dépêche

Posté par Philip Marlowe le 04 mars 2016 à 16:44. Évalué à 3.

Ce journal […]

Cette dépêche […]
- [^] # Re: Changement en dépêche
  
  Posté par patrick_g (site web personnel) le 04 mars 2016 à 17:24. Évalué à 3.
  
  Corrigé.
- [^] # Re: Changement en dépêche
  
  Posté par trancheX le 09 mars 2016 à 12:31. Évalué à 2. Dernière modification le 09 mars 2016 à 12:34.
  
  Y a un truc qui m'embête avec tout ses "superset" de JS/HTML/DOM : c'est qu'on perd la visibilité dans le navigateur du code exécuté.
  
  Je m'explique : un truc que je trouve génial en web c'est que en faisant du html/JS/CSS ont peu faire une web-app assez simplement et surtout on l’exécute dans le navigateur et lorsqu'on ouvre la console web on a directement accès à son code, ont peut tout déboguer/changer facilement; et les outils de débogue/profilage des navigateurs sont vraiment au poil.
  Pour faire du C embarqué et du C++ de temps à autre, je trouve ça génial : jamais mettre en place le débogage/profilage d'une application ne m'a été rendu si simple !
  
  Franchement, je m’accommode bien des défaut du JS et je ne suis pas prêt de passer à CoffeScript/Typescript/SASS/Elm/etc car en les utilisant ce que je verrais dans la console web sera généré par ses outils ça ne sera plus mon code, ça ajoute une couche d'indirection et je trouve que ça n'en vaut donc pas la peine.
  
  Est ce que je passe à côté de quelque chose ? Elm a-t-il des outils pour déboguer/visualiser/modifier aussi facilement son code que du vanilla HTML/JS ?
  
  NOTE : oups je voulais répondre à @macadoum sur Elm ( "Elm, c'est la grande classe." ), si qqn peut déplacer mon commentaire
  - [^] # Re: Changement en dépêche
    
    Posté par Bruno Michel (site web personnel) le 09 mars 2016 à 12:53. Évalué à 6.
    
    Est ce que je passe à côté de quelque chose ? Elm a-t-il des outils pour déboguer/visualiser/modifier aussi facilement son code que du vanilla HTML/JS ?
    
    Oui, il y a des outils pour faire tout ça. D'ailleurs, un article montre comment rejouer des interactions pour tester une nouvelle version du code : http://elm-lang.org/blog/time-travel-made-easy. C'est assez impressionnant !
  - [^] # Re: Changement en dépêche
    
    Posté par djano le 09 mars 2016 à 21:32. Évalué à 2.
    
    Oui il y a les sourcemaps
# La mort de l'ECMAScript, c'est pas pour demain

Posté par damaki le 04 mars 2016 à 16:53. Évalué à 7.

Le JavaScript, qu'on l'aime ou pas, est bien parti pour durer. Qu'on admire ses qualités ou qu'on haïsse ses défauts, ça ne changera rien au fait que c'est le langage de script pour navigateur et que, vu son inertie, ça risque de perdurer encore pour un paquet d'années. Partant de là, soit on contourne le problème en utilisant babel, CoffeeScript ou tous leurs copains qui customisent le langage, soit on l'accepte tel qu'il est. Même bourré de défauts, avec un environnement de dev peu fiable (node et tous ses packages npm boiteux, oui même babel a des bugs pénibles), il faut accepter de vivre avec. Haters gonna hate.

JavaScript à mon sens est comme le C, le C++, l'ObjectiveC et le Java, ces langages qui sont désormais un peu partout et dont on ne se débarrassera pas avant des lustres.
- [^] # Re: La mort de l'ECMAScript, c'est pas pour demain
  
  Posté par Sytoka Modon (site web personnel) le 04 mars 2016 à 19:37. Évalué à 5.
  
  La machine virtuelle n'est pas prête de changer mais à partir du moment ou l'on va charger du code javascript binaire, on pourra utiliser n'importe quel langage qui cible cet assembleur…
- [^] # Re: La mort de l'ECMAScript, c'est pas pour demain
  
  Posté par pushmepullme le 04 mars 2016 à 22:35. Évalué à 1.
  
  JavaScript à mon sens est comme le C, le C++, l'ObjectiveC et le Java, ces langages qui sont désormais un peu partout et dont on ne se débarrassera pas avant des lustres.
  
  Complètement. Au même titre que ouinouin, le batch, le x86, etc. Si t'es premier ou que tu as un bon service marketing, tu peux imposer ton bousin pour des lustres.
# Elm

Posté par macadoum le 04 mars 2016 à 16:55. Évalué à -4.

Elm, c'est la grande classe.
- [^] # Re: Elm
  
  Posté par lasher le 06 mars 2016 à 21:25. Évalué à 4.
  
  Je préfère Pine, car Pine Is Not Elm.
  
  … Quoi, on n'est pas dans une dépêche-troll sur les MUA?
# mes 5 cents tout ca tout ca

Posté par Xarkam (site web personnel) le 04 mars 2016 à 17:18. Évalué à -3.
```
> Ici, l'héritage du JavaScript pèse lourd dans la balance. Il y a trop de pièges, trop de comportements qui demandent une attention permanente (perdre le this, se tromper dans la portée d'une variable).
```
C'est le b-a-ba de tout dev de connaitre la portée des variables dans le langage qu'il utilise ainsi que les subtilités.

On parle souvent du nombre impressionnant de paquets publiés sur npm. Pourtant, quand on y regarde de plus près, c'est loin d'être reluisant. On trouve des tonnes de paquets qui sont des expérimentations qui n'ont jamais dépassé le stade de la version 0.0.x.

C'est pareil pour linux alors, on trouve des tonnes de lib et soft en 0.x.x.

Node.js ne fait pas mieux. Il faut toujours installer un paquet pour faire un mkdir -p, ou un rm -rf (d'ailleurs, vous risquez de vous retrouver avec rimraf et del si vous ne faites pas attention).

C'est surtout le revert de la médaille de tout écosystème opensource. On peu en dire autant pour linux avec ces moult distrib.

Enfin, certaines entreprises ont les dents longues et il n'est pas rare d'en venir aux drames pour parfois faire avancer les choses. On se rappelle du fork io.js pour soustraire nodejs de l'emprise de Joyent. Plus récemment, c'est le principal contributeur d'express qui a jeté l'éponge (et même deux fois) pour des raisons similaires. On peut aussi s'amuser de github transformé en bac à sable. Mais ce qui est sûr est qu'il y a bien des progrès à faire dans ce domaine

Pareil, ce n'est pas quelque chose de propre au monde js.

Dernier point, avec ES6 et les versions futures, je trouve le langage de plus en plus complexe. Mais surtout cette complexité ne répond pas à mes besoins.

Non, le langage ne répond pas à "ses besoins" et il fait donc une un plaidoyer pour s'en débarrasser.

Mais js n'est pas plus complexe qu'un autre. Ca ne fait même pas une année que je fait du js et si quelque chose est compliqué, je cherche un moyen simple de le faire. Simply is better.

Mon ressenti final, c'est que ce développeur à du mal avec la manière dont le code js est exécuté. Mais dès qu'on a compris, si on code comme dans tout langage, de manière classique, js n'est pas plus compliqué.

Après, je ne dit pas, ma femme fait du js bien plus compliqué que moi, genre des structures js à 3 niveaux, pourtant, elle ne me semble pas peiner quotidiennement à la tâche de faire du js.
- [^] # Re: mes 5 cents tout ca tout ca
  
  Posté par CrEv (site web personnel) le 04 mars 2016 à 17:42. Évalué à 7.
  
  Mon ressenti final, c'est que ce développeur à du mal avec la manière dont le code js est exécuté. Mais dès qu'on a compris, si on code comme dans tout langage, de manière classique, js n'est pas plus compliqué
  
  Désolé, mais j'ai ri :-)
  
  Et pour le reste, ce n'est pas parce que certains problèmes se retrouvent ailleurs que ça n'en fait pas des problèmes
  - [^] # Re: mes 5 cents tout ca tout ca
    
    Posté par Xarkam (site web personnel) le 04 mars 2016 à 17:55. Évalué à 1.
    
    Et pour le reste, ce n'est pas parce que certains problèmes se retrouvent ailleurs que ça n'en fait pas des problèmes
    
    Je n'ai jamais dit que ce n'était pas des problèmes.
    La prose du mec est faite de manière à comprendre que tout les problèmes dans le monde javascript sont dû à javascript.
    
    Mais comme l'a fait remarquer damaki, l'auteur se plaint de lib en 0.x.x et propose lui même des alternatives en version 0.x.x
    
    On ne sais en déduire qu'une chose, cette personne fait une charge contre js avec un certain manque d'objectivité.
    
    80% de son argumentaire ne tient pas la route car ce sont des problèmes inhérent au monde de l'opensource.
    - [^] # Re: mes 5 cents tout ca tout ca
      
      Posté par j_m le 05 mars 2016 à 09:42. Évalué à 8.
      
      On ne sais en déduire qu'une chose, cette personne fait une charge contre js avec un certain manque d'objectivité.
      
      Tu critiques l'article comme si il te proposait d'abandonner le Javascript dans ton prochain projet au boulot.
      
      C'est pas du tout ça. Sinon l'auteur n'aurait pas mentionné les petits languages tout nouveaux mais un language concurrent qui peut remplir le même rôle que javascript. De plus il aurait fallut parler des framework et de ce qu'ils permettent de faire.
      
      A mon avis, l'article est plutôt écrit du point de vue de celui qui doit concevoir des languages. Quels piègent se profilent ? Quels choix sont dangereux ou mauvais ? Pourquoi ? Qu'est-ce qu'un bon language ?
    - [^] # Re: mes 5 cents tout ca tout ca
      
      Posté par CrEv (site web personnel) le 05 mars 2016 à 10:40. Évalué à 9.
      
      80% de son argumentaire ne tient pas la route car ce sont des problèmes inhérent au monde de l'opensource
      
      Mais encore une fois en quoi ça ne tient pas la route ? Ce n'est pas parce qu'un certains nombre de problèmes sont présent de manière plus globale dans le monde opensource que ce n'est pas un problème au global et que, appliqué au cas de javascript, ce n'est pas un problème en particulier.
# Version 0.x.x

Posté par damaki le 04 mars 2016 à 17:45. Évalué à 1. Dernière modification le 04 mars 2016 à 17:47.

Tous les langages cités dans l’article, sauf Elixir, sont en version 0.x.x. Je sais pas vous, mais moi ça me gêne beaucoup plus d'utiliser un langage dans une version supposé non stable qu'une lib supposée non stable. Le langage non stable, c'est plus difficile à tester unitairement pour prouver des bugs qu'une librairie.
Pourquoi cette différence de traitement ?
Pourquoi glorifier des langages en supposée bêta ?

Ou est-ce que tout simplement ça ne voudrait pas dire que le semantic versioning n'est pas utilisé correctement par beaucoup de projets et que ça ne veut pas dire grand chose ? Et donc que ça n'apporte pas grand chose au débat contre les librairies javascript ?
Je suis d'accord que beaucoup de librairies javascript sont mal maintenues, mais c'est effectivement un problème assez générique dans le monde de l'open source. Certaines libs, certains logiciels sont maintenus professionnellement, pas d'autres. Mais ça ne tient qu'à vous d'accepter le fait dans vos projets que si vous trouver un bug ou une fonctionnalité dans une librairie open source: corrigez et faites une pull request ou une fork.
- [^] # Re: Version 0.x.x
  
  Posté par Antoine le 04 mars 2016 à 18:29. Évalué à -1. Dernière modification le 04 mars 2016 à 18:30.
  
  Il y a peut-être un côté hipster de l'informatique : maintenant que Javascript s'est complètement massifié, certains ressentent le besoin de vanter de petits langages obscurs, des créations patientes d'artisans, des éléments de distinction qui montrent qu'on ne se laisse pas aller au mainstream (*). Il est vrai que je n'avais entendu parler d'aucun des langages cités par la dépêche.
  
  Des langages qui apportent des solutions élégantes à un petit sous-ensemble de problèmes, ça a toujours existé. La grosse difficulté, c'est de faire un langage généraliste—et son écosystème—qui reste "élégant", c'est-à-dire productif et facile à apprendre, tout en s'adaptant à une multitude de cas d'usage. C++ et (dans une moindre mesure) Python ont le même problème.
  
  (*) Distinction au sens de Bourdieu :
  
  En faisant de La Distinction une critique sociale du jugement, Pierre Bourdieu bouleverse d’emblée des catégories sur le Beau, l’art et la culture, qui n’avaient jamais été remises en question. Non seulement le beau n’est pas un concept a priori, mais, au contraire, “ les gens ont le goût de leur diplôme ” et, les catégories de la distinction dépendent de la position que l’on a dans le tableau des classes sociales. Ainsi, selon que l’on a fait des études supérieures ou que l’on a passé le B.E.P.C., que l’on est issu de la bourgeoisie ou d’une classe populaire on aime le Clavecin bien tempéré, la Rhapsodie in blue ou le Beau Danube bleu.
  - [^] # Re: Version 0.x.x
    
    Posté par Guillaume Denry (site web personnel) le 04 mars 2016 à 18:57. Évalué à 4.
    
    Il y a peut-être un côté hipster de l'informatique : maintenant que Javascript s'est complètement massifié, certains ressentent le besoin de vanter de petits langages obscurs, des créations patientes d'artisans, des éléments de distinction qui montrent qu'on ne se laisse pas aller au mainstream (*).
    
    On pourrait utiliser exactement le même argument à chaque fois qu'un nouveau langage naît.
    
    Je trouve ta réaction incroyable. Tu ne connais pas ces langages ni à quelle problématique ils répondent mais tu te permets de les balayer d'un revers de la main en affirmant qu'ils ne sont que des outils de hype et de distinction.
    
    C'est pour moi pire que tout, pire que de faire du hype par exemple :)
    - [^] # Re: Version 0.x.x
      
      Posté par Antoine le 04 mars 2016 à 22:02. Évalué à 3.
      
      Tu ne connais pas ces langages ni à quelle problématique ils répondent mais tu te permets de les balayer d'un revers de la main en affirmant qu'ils ne sont que des outils de hype et de distinction.
      
      Pas du tout. J'ai dit "des langages qui apportent des solutions élégantes à un petit sous-ensemble de problèmes". Il s'agit bien d'expérimentations sérieuses de la part de leurs auteurs, enfin j'imagine…
      
      Maintenant, prétendre que Javascript va dans le mur parce qu'il existe cinq langages inconnus et expérimentaux, sans base utilisateurs, sans écosystème, qui ont choisi des solutions différentes, cela me paraît particulièrement léger et c'est pour cela que je proposais une explication d'ordre sociologique.
      
      Je note que cette tendance à valoriser des langages peu connus et peu éprouvés date d'il y a une dizaine d'années, et qu'on en a déjà vu passer un certain nombre…
      - [^] # Re: Version 0.x.x
        
        Posté par Bruno Michel (site web personnel) le 05 mars 2016 à 14:15. Évalué à 9.
        
        Je note que cette tendance à valoriser des langages peu connus et peu éprouvés date d'il y a une dizaine d'années, et qu'on en a déjà vu passer un certain nombre…
        
        C'est même probablement plus vieux que ça. Mais bon, je pense que tous les langages ont été peu connus et peu éprouvés à un moment. Il y en a même qui ont défendu le Python à une époque…
        
        [^] # Re: Version 0.x.x
        
        Posté par Moonz le 05 mars 2016 à 15:23. Évalué à 10.
        
        Quitte à jouer à « même ce langage était peu connu et éprouvé à une époque », on peut évoquer… javascript, longtemps considéré comme un jouet pour faire des trucs genre « Entrez votre nom » « Bonjour "nom" » sur un site perso, et son utilisation côté serveur non seulement impossible mais impensable.
        
        Le mainstream de demain c’est le jouet d’aujourd’hui, même si tout jouet d’aujourd’hui ne sera pas un mainstream demain. Le jeu c’est justement d’avoir le flair pour trouver lequel ;)
- [^] # Re: Version 0.x.x
  
  Posté par Sytoka Modon (site web personnel) le 04 mars 2016 à 19:44. Évalué à 10.
  
  Je suis d'accord que beaucoup de librairies javascript sont mal maintenues, mais c'est effectivement un problème assez générique dans le monde de l'open source.
  
  Je pense que beaucoup de langage n'ont pas compris la force d'un vrai CPAN. Plutôt que d'avoir 1500 modules à plat en foutoir, on monte une arborescence de nom de manière collaborative. Ainsi les branches bien conçues et maintenues prennent rapidement de l'importance et sont étendues.
- [^] # Re: Version 0.x.x
  
  Posté par wilk le 04 mars 2016 à 20:49. Évalué à 7.
  
  Utiliser un langage en cours de mise au point est au contraire tellement plein d'enseignements ! Même si on doit en utiliser un autre pour l'alimentaire il y a toujours moyen de progresser et d'améliorer sa pratique dans son langage actuel.
  
  Je remercie donc particulièrement les auteurs de journaux ou dépêches qui partagent leurs découvertes et nous permettre d'en débattre.
  - [^] # Re: Version 0.x.x
    
    Posté par damaki le 09 mars 2016 à 10:38. Évalué à 2.
    
    Pour le côté hobby et apprentissage, oui. Par contre tu me feras pas mettre en prod un soft fait avec un de ces langages.
    C'est le même principe avec les OS alternatifs qui existent plutôt dans une optique de découverte que pour créer un vrai OS qui sera utilisé au quotidien.
    Mais ça n'est pas parce que ça n'a pas un objectif professionnel que ça n'a pas de valeur. Apprendre de nouveaux concepts, ça peut permettre de les appliquer dans d'autres langages, même ceux qui n'ont pas les constructions adéquates. On peut parfaitement faire de la programmation objet en C. Faudra juste mettre de côté l'héritage et se contenter du polymorphisme, puis passer this en premier paramètre de méthode.
- [^] # Re: Version 0.x.x
  
  Posté par Bruno Michel (site web personnel) le 05 mars 2016 à 14:09. Évalué à 10.
  
  Mon point n'était pas de dire qu'il ne faut plus utiliser le JavaScript dès aujourd'hui et passer à ces langages inconnus. Ces langages sont des expérimentations, pas un truc solide pour construire des applications qui iront en production aujourd'hui. Mais étudier ces langages restent utile, on apprend des outils et des façons différentes de coder.
  
  Ces terrains d'expérimentation permettent souvent d'avoir une idée des concepts que l'on retrouvera dans quelques années dans les langages majeurs. Par exemple, les channels et goroutines de Go ont beaucoup profité des expériences de 2 langages obscurs : occam et limbo (d'ailleurs, ce n'est pas étonnant, Rob Pike est l'un des créateurs de Limbo et de Go). Les lambdas de Java 8 sont arrivées après celles de Groovy (et autres langages basés sur la JVM). Et bien entendu, un bon paquet des fonctionnalités introduites dans ES6 viennent de CoffeeScript.
  
  Au final, ma question n'est pas de dire par quoi on va remplacer JavaScript aujourd'hui, mais dans quel état il sera dans quelques années. Ces dernières années, le nombre de développeurs JS a clairement augmenté. Mais je crains que le JavaScript (langage, outils, écosystème) n'aille dans une mauvaise direction.
  
  Quant à m'expliquer que je dois participer à des bibliothèques Open Source, c'est assez naïf. Ça fait un paquet d'années que je le fais, comme mon compte github pourrait l'attester. Cela inclut des bibliothèques JS, comme moment ou forever.
  - [^] # Re: Version 0.x.x
    
    Posté par damaki le 09 mars 2016 à 10:43. Évalué à 1.
    
    Quant à m'expliquer que je dois participer à des bibliothèques Open Source, c'est assez naïf. Ça fait un paquet d'années que je le fais, comme mon compte github pourrait l'attester. Cela inclut des bibliothèques JS, comme moment ou forever.
    
    Tu as mal compris mon propos. Ce que je voulais simplement dire, c'est que quand on utilise une lib open source avec peu de contributeurs, en 0.x.x ou pas, faut prendre en compte qu'il faudra peut-être la maintenir soi même. C'est une bonne pratique générale, pas une attaque personnelle.
    - [^] # Re: Version 0.x.x
      
      Posté par Bruno Michel (site web personnel) le 09 mars 2016 à 13:02. Évalué à 4.
      
      Quand on utilise une lib open source avec peu de contributeurs, en 0.x.x ou pas, faut prendre en compte qu'il faudra peut-être la maintenir soi même.
      
      On est bien d'accord. Et comme c'est le cas de quasiment tous les modules sur npm, on se retrouve rapidement à faire beaucoup de maintenance soi-même. Dans d'autres langages, les acteurs (entreprises et communauté) créent moins de paquets mais maintiennent mieux l'existant.
# Ca va en s'améliorant

Posté par mikael.vallerie le 04 mars 2016 à 18:33. Évalué à 5.

Il y a bien sûr l'immutabilité […]

Pour le moment, le workaround qui me convient le plus est Immutable.js

Un coup, ce sont des require CommonJS, l'autre des import/export d'ES6. Et je ne parle même pas du temps fou qu'il faut passer pour réussir à les compiler. Et quand vous avez un outil qui marche, vous pouvez être sûr que dans quelques mois, ses plugins pour faire du sass ou générer des sprites ne seront plus maintenus.

Rarement eu ce genre de problème sur un projet sérieux…c'est sûr que celui qui clone n'importe quel skeleton fait à l'arrache sur github, et qui n'utilisera même pas 10 % de ce que propose ledit skeleton, il va se heurter à ce type de souci. Je suis partisan de minimiser au maximum l'aspect build d'un projet. Webpack + Babel + ESLint + WhateverTestTool, ça permet déjà de faire énormément de choses.

Celui-ci continue de gagner en popularité, mais aussi en complexité.

Tout dépend AMHA de la définition donnée à "complexité". Pour moi, ES6 est plus "simple" que jamais, et franchement, il était temps. Non pas que je n'aimais pas les surcouches type CoffeeScript, mais tendre vers l'unification, je trouve ça bien.

Il est pour moi clair que Javascript a accumulé une dette technique considérable. Ca s'améliore petit à petit…..vraiment petit à petit (un bon support ES6 natif sur les navigateurs, ce serait déjà pas mal). C'est le revers de la médaille. A côté de ça, on a un langage exécutable à peu près partout (une application mobile tout en Javascript c'est très faisable), et un écosystème assez exceptionnel (merci CommonJS, merci AMD).

Et vous, quels sont vos langages du moment ? Et que font-ils mieux que JavaScript ?

A titre personnel, je préfère cent fois écrire du ScalaJS. Mais avec ES6, je ne me sens plus obligé de le faire, même si je reste frustré par certains manques. Et quand je vois mes builds ScalaJS saturer mes 4GB de mémoire (oui ok on est en 2016…mais quand même), quand Webpack et Babel tournent comme des fleurs, ça me fait vraiment mal au coeur.
- [^] # Re: Ca va en s'améliorant
  
  Posté par karchnu le 05 mars 2016 à 21:23. Évalué à 4.
  
  Avoir un outil qui consomme tellement de ressources est clairement un symptôme. Quand un outil est bien pensé il ne va pas mettre à genoux ton ordinateur.
# Un tag pour les gouverner tous

Posté par jigso le 04 mars 2016 à 20:16. Évalué à 9. Dernière modification le 04 mars 2016 à 20:17.

À quand des extensions pour pouvoir faire : < script type="text/mon_super_langage_de_la_mort" > ?

Perso, je rève d'un text/perl…
- [^] # Re: Un tag pour les gouverner tous
  
  Posté par ɹǝɓuᴉɹǝɐH ʅǝnuɐɯɯƎ-sᴉxǝʅⱯ le 04 mars 2016 à 20:44. Évalué à 3.
  Votre rêve existe, Microsoft l'a fait ! :)
```
<Job Id="WshShell">
<script language=PerlScript>
    $WshShell = $WScript->CreateObject("WScript.Shell");
    $WshShell->Run("notepad");
    $WshShell->AppActivate("Sans titre - Bloc-notes");

    my $message = "J aime l activX PerlScript !\n";

    for($i=0; $i < length($message); $i++) {
        $char = substr($message, $i, 1);
        $WScript->Sleep(100);
        $WshShell->SendKeys($char);
    }
</script>
</job>
```
  - [^] # Re: Un tag pour les gouverner tous
    
    Posté par baobab le 07 mars 2016 à 14:59. Évalué à 4.
    Dans le même esprit il y a ça, open source, norme python 3.3, compatible toutes plateformes et créé par un français :)
    
    C'est converti en javascript a la volée.
    
    Je trouve que c'est un beau projet, a suivre donc.
    
    http://brython.info
```
<html>
<head>
<script src="http://brython.info/src/brython_dist.js"></script>
</head>
<body onload="brython()">
<script type="text/python">
from browser import document, alert

def echo(ev):
    alert(document["zone"].value)

document['mybutton'].bind('click',echo)
</script>
<input id="zone"><button id="mybutton">click !</button>
</body>
</html>
```
- [^] # Re: Un tag pour les gouverner tous
  
  Posté par Sytoka Modon (site web personnel) le 05 mars 2016 à 14:54. Évalué à 5.
  Cela a marché il y a 20 ans environ… Mais je ne retrouve guère de trace. Il y avait quelques soucis de sécurité (La version native de Perl donne accès aux fichiers locaux par exemple) et pratique (déployer et maintenir l’interpréteur sur des postes clients multi-plateforme.
  - http://www.brainbell.com/tutors/Perl/newfile295.html
  - http://docstore.mik.ua/orelly/perl3/tk/ch22_02.htm
  En //, crosoft nous a fait chier avec ActiveX… Je pense que la bonne idée est de normaliser la machine virtuelle binaire plutôt que de vouloir le faire au niveau du langage. Il y aura toujours une guerre de chapelle pour dire que la sienne est la plus belle ;-)
- [^] # Re: Un tag pour les gouverner tous
  
  Posté par djano le 09 mars 2016 à 21:40. Évalué à 2.
  
  Toi tu as oublié comme le vbscript sous internet explorer c'était trop bien… ou pas!
# Mithril

Posté par Benoît Laurent (site web personnel) le 04 mars 2016 à 22:02. Évalué à 5.

Dans le journal ou ici, personne n'a encore parlé de Mithril

L'API est petite, il ne force pas le choix d'une variante de JS ou d'un système de build et semble proposer tout le nécessaire.

Voir aussi cette présentation avec ses exemples : https://github.com/nordfjord/mithrilexamples/

Vous l'avez essayé ? Qu'en pensez-vous ?
- [^] # Re: Mithril
  
  Posté par lateralus_ le 05 mars 2016 à 10:39. Évalué à 4.
  
  On utilise Mithril dans notre boîte depuis quelques mois et on est agréablement surpris du résultat.
  
  L'API est en effet toute petite, ce qui permet une prise en main rapide.
  Le code est plus clair et concis que précédemment (on utilisait principalement jQuery): plutôt que d'interagir en permanence avec le DOM, on se concentre plutôt sur ce que l'on veut voir afficher à l'écran et Mithril se charge du reste (grâce notamment au Virtual DOM).
  Mithril est relativement peu obstrusif: on peut utiliser aussi bien des fonctions et des objets littéraux (ES5) que des classes(ES6).
  
  Le seul point faible reste la communauté assez restreinte (comparativement à React par exemple).
  On avait essayé à l'époque d'utiliser JSX pour décrire la vue avec le plugin babel mjsx mais on a dû faire marche arrière car ça créait notamment des problèmes lors du build.
  - [^] # Re: Mithril
    
    Posté par Dreammm le 06 mars 2016 à 12:41. Évalué à 1.
    
    J'ai pas mal galéré il n'y a pas longtemps sur le sujet. Tu peux trouver le résultat (couronné de succès !) sur github.
    
    N'hésite pas à envoyer des remarques sur la chose.
# "promu" en dépêche

Posté par steph1978 le 05 mars 2016 à 22:41. Évalué à 10.

Je suis dubitatif quant à l'intérêt de la promotion en dépêche.
Je n'y vois que l'inconvénient de disperser les discussions dans deux posts.
Pour preuve : 92 commentaires sur le journal, 27 sur la dépêche.
Si c'est pour donner plus de visibilité à un contenu plébiscité, pourquoi ne pas le convertir en dépêche, sans perdre les commentaires ?
Pour ma part j'affiche journaux et dépêches sur la première page. Donc pas intéressé par les "promotions".
- [^] # Re: "promu" en dépêche
  
  Posté par Bruno Michel (site web personnel) le 06 mars 2016 à 13:37. Évalué à 10.
  
  Oui, il faudrait faire ça. Quand j'ai codé ça, je me suis appuyé sur l'avis des modérateurs de l'époque. À l'usage, on s'est effectivement rendu compte que ce n'était pas idéal. D'ailleurs, il y a une entrée de suivi à ce sujet. Si un volontaire veut envoyer un patch, je m'engage à le relire, l'intégrer et le déployer en production rapidement.
# Et bé...

Posté par Patrice FERLET (site web personnel) le 06 mars 2016 à 11:48. Évalué à 3.

… tout ça pour un langage de script qui est voué, à la base, au navigateur…

JS est comme tout langage de script, si tu codes correctement, ce langage est superbe. Il a ses défauts, ses qualités, ses bizarreries.

Personnellement, je trouve que AngularJS montre à quel point on peut faire de beaux projets à condition d'être un développeur sérieux. Et je suis en plein dans Angular 2 qui propose d'utiliser Typescript (qui n'est ni plus ni moins qu'un subset de JS hein) avec les nouveautés de ES6.

Lors de mon passage aux WebBlendMix (où j'ai donné une conf (pub perso)) il y avait une superbe conférence de C.Porteneuve qui a montré la puissance et l'intérêt de ES6 => https://www.youtube.com/watch?v=uL9uAAzkFmI

Non, JS n'est pas mort, il va perdurer, évoluer, apporter pleins de choses nouvelles.

La seule chose sur laquelle je rejoins la critique, c'est "NPM" qui est pour moi un bloat sans nom. Installer Angular 2 demande des centaines de megaoctet de dépendances… Cela-dit, ça a le mérite de faire les choses qu'on lui demande et pour peu qu'on soit professionnel dans l'approche, JS reste vraiment un langage intéressant et adapté.

Petit rappel, JS n'est que ES en fait, un langage standardisé qui est quasi-compatible avec les autres langages ES dérivés… Donc JS a de beaux jours devant lui.
- [^] # Re: Et bé...
  
  Posté par Bruno Michel (site web personnel) le 06 mars 2016 à 13:32. Évalué à 5.
  2 petites précisions sur cette phrase :
  
  Typescript (qui n'est ni plus ni moins qu'un subset de JS hein) avec les nouveautés de ES6
  - Typescript est un superset, pas un subset de JS. Il propose le typage en plus (avec sa syntaxe).
  - La prise en charge d'ES6 par Typescript n'est pas mauvaise, mais reste en-dessous de celle proposée par Babel, traceur, Chrome, Firefox ou Edge. Par contre, Typescript a aussi commencé à prendre en charge des évolutions futures de JavaScript, comme Array.prototype.includes (ES2016), Object.values et Object.entries (stage 3 et très certainement dans ES2017) et même async/await (stage 3, mais aucune implémentation existante dans les navigateurs, donc chances assez mitigées d'être dans ES2017).
  - [^] # Re: Et bé...
    
    Posté par Bruno Michel (site web personnel) le 06 mars 2016 à 20:38. Évalué à 5.
    
    Et pour rire 2 minutes, voici les numéros de la dernière version de typescript :
    
    This release has the version tag of 1.8.5.0 for Visual Studio 2013, 1.8.6.0 for NuGet and Visual Studio 2015 and 1.8.7.0 for npm.
    
    Source : https://github.com/Microsoft/TypeScript/releases
  - [^] # Re: Et bé...
    
    Posté par Patrice FERLET (site web personnel) le 09 mars 2016 à 00:21. Évalué à 1.
    
    Le pire c'est que j'avais "superset" dans la tête, j'ai dérapé.
    
    En ce qui concerne certaines implémentations non intégrées dans Typescript, comme async/await, franchement du moment que j'ai d'autres méthodes qui me permettent de faire cela sans contrainte… Franchement je me suis mis à Typescript depuis un petit mois et je trouve ce langage très intéressant (notamment pour bosser sur Angular 2). Qu'il soit full ES6 compliant ou qu'il s'en approche n'a que peu d'importance à mes yeux (c'est personnel hein, il se peut que ça soit bien plus important pour d'autres, ce que je comprends parfaitement). Mais l'idée de mon message est de dire que ce titre un poil racoleur pour tenter de dire que "JS c'est de la daube d'un ancien temps" me parait limite quand on voit l'effort de fait par la communauté (y compris Microsoft pour le coup) pour tendre vers de la qualité et des performances.
    
    ES6 est une vraie bonne nouvelle, TS apporte un sacré lot de plaisirs à coder, et par conséquent je ne pense vraiment pas que nous soyons dans une mauvaise direction avec JS.
    
    Voilà :)
# Pour rire

Posté par Blackknight (site web personnel, Mastodon) le 06 mars 2016 à 19:47. Évalué à 7.

Bon, je l'avoue, je n'aime pas le Javascript mais, là, c'est juste pour vous faire partager une petite vidéo très amusante :)
- [^] # Re: Pour rire
  
  Posté par Lutin le 07 mars 2016 à 14:15. Évalué à 4.
  
  http://thedailywtf.com/articles/bidding-on-security
  Les commentaires sont très drôles ^{^}
- [^] # Re: Pour rire
  
  Posté par Patrice FERLET (site web personnel) le 09 mars 2016 à 00:28. Évalué à 1.
  
  J'ai choppé un fou-rire sur le "watman", merci !
# Dans toute cette jungle...

Posté par Wawet76 (site web personnel) le 06 mars 2016 à 22:18. Évalué à 2.

Si vous deviez commencer un projet en Javascript aujourd'hui (disons côté client), qu'est ce que vous prendriez comme outils de build et de test ?
- [^] # Re: Dans toute cette jungle...
  
  Posté par Bruno Michel (site web personnel) le 07 mars 2016 à 09:50. Évalué à 3.
  
  Pour le build, je passe mon tour. Pour les tests, ça dépend si je veux quelque chose d'éprouvé ou si je peux me permettre d'expérimenter.
  
  Pour la version éprouvée, je me tournerais vers Mocha, avec ses amis chai et sinon.
  
  Pour l'expérimental, je prendrais painless. L'approche me plaît beaucoup, il y a des fonctionnalités intéressantes mais ça n'a pas l'air très utilisé pour le moment.
  - [^] # Re: Dans toute cette jungle...
    
    Posté par barmic le 07 mars 2016 à 10:08. Évalué à 5.
    
    J'ai un petit problème personnellement avec les tests. Mon code JS est vraiment du code glue. C'est de l'angular et c'est vraiment juste une interface entre mes vues et des appels de webservices. Tester unitairement ce code ne fais pas beaucoup de sens parce qu'il ne porte pas vraiment de logique.
    
    Vous connaissez des choses pour faire des tests de recette autre que selenium qui fait pas vraiment rêver ? (la techno qui est derrière je m'en fout je veux juste pouvoir tester vraiment mes vues)
    
    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Dans toute cette jungle...
      
      Posté par Nicolas (site web personnel) le 07 mars 2016 à 11:17. Évalué à 2.
      
      Si selenium ne te fait pas rêver regarde du côté de casper
    - [^] # Re: Dans toute cette jungle...
      
      Posté par El Titi le 07 mars 2016 à 14:09. Évalué à 3. Dernière modification le 07 mars 2016 à 14:09.
      
      Pour les test E2E avec Angular, la recommandation est protractor qui permet de tester directement les directives d'Angular et surtout qui gère l'asynchrone. Il faut coupler ça avec Karma.
# Merci !!!

Posté par romu le 07 mars 2016 à 14:05. Évalué à 10.

Merci beaucoup pour cette dépêche, je m'y retrouve bien. Je viens de C++/C#/Java, même si depuis quelques années maintenant, je ne code plus au quotidien. Mais faut pas mourir idiot, et je me suis dit que mettre au dev web ce serait bien.

Je tente de développer quelques trucs en back end avec Node. Et comme à chaque fois que je vois du code Js, j'ai du mal à comprendre, revenir aux fondamentaux du langage m'a semblé une bonne idée.

Et c'est là que je rejoins cette dépêche. D'ailleurs, je suis très surpris de lire un peu partout que Js est un langage facile à apprendre. Car j'ai l'opinion totalement inverse, Js est tout sauf simple comme tu le soulignes. Un exemple ? Il y a 3 façons différentes de créer des objets ("Object literal", fonction constructeur et mot clé "class"), et là, WTF !! Ces 3 façons de coder ayant chacune ses avantages et ses inconvénients, mais attention, ce ne sont pas les mêmes selon que tu lis la prose d'untel ou d'un autretel, re WTF si il n'y a pas moyen d'avoir une information fiable et objective sur un tel sujet.

Sans compter aussi le côté foutoir de l'écriture de fonctions entre les déclarations, expressions, lambda, anonyme, closure, etc.
Et sans parler de la jungle des frameworks, aussi bien client que serveur (c'est à peine mois le bordel, mais juste à peine).

Tout ça semble peut-être facile à quelqu'un qui baigne dedans depuis longtemps, mais pour quelqu'un qui a envie de prendre le train en marche, impossible d'y voir clair. Je lisais récemment un article sur ce sujet, et l'auteur disait qu'il faisait le maximum de choses côté serveur, dans la techno qu'il maîtrise le plus, pour éviter le foutoir ambiant côté client.
# Dart

Posté par woopla le 07 mars 2016 à 18:22. Évalué à 6.

Il a déjà été mentionné dans le journal à l'origine de la dépêche, mais une précision importante à son sujet: Dart est aussi un standard ECMA, le 408.

J'ai beaucoup de mal avec la syntaxe de Javascript, je trouve la chose assez brouillonne - enfin pas adapté à mon cerveau qui aime beaucoup le Tcl et le Go :)

Et comme beaucoup d'autres personnes, l'écosystème JS est un beau bordel. Le nombre de frameworks et de bibliothèques qui font la même chose est hallucinant. J'ai l'impression que plutôt que de faire des patches sur un système existant, l'état d'esprit est beaucoup plus à repartir de zéro. Du coup quand on débarque là-dedans, c'est comme débarquer dans un hypermarché pour la première fois, sans mode d'emploi. Certes il y a du choix, mais des fois le choix ça donne des boutons :)
# Change de lunettes !

Posté par Axioplase ıɥs∀ (site web personnel) le 09 mars 2016 à 20:06. Évalué à 3.

l’auteur du journal a étudié d’autres langages […] et ceux‐ci lui ont fait sauter aux yeux les défauts du JavaScript.

Tu veux dire que t'avais pas vu les défauts de JavaScript qui sont là depuis 1995 ?
- [^] # Re: Change de lunettes !
  
  Posté par Bruno Michel (site web personnel) le 10 mars 2016 à 12:11. Évalué à 5.
  Tu veux dire que t'avais pas vu les défauts de JavaScript qui sont là depuis 1995 ?
  
  C'est difficile de comparer le JavaScript de 1995, ou même celui de 2005, à celui d'aujourd'hui. D'abord, le langage a évolué, son écosystème aussi. Mais surtout, on ne fait plus la même chose avec. Pour écrire 10 ou 100 lignes de code qui rendent un site un peu plus dynamique, JavaScript me convient bien. Pour faire une application complète, beaucoup moins.
  
  D'ailleurs, la plupart des défauts que je cite dans le journal, j'aurais eu bien du mal à les citer il y a 10 ans (en 1995, je ne faisais pas de JS). Et je doute que beaucoup d'autres développeurs les aient vu à cette époque là.
  - Asynchrone : en 2005, je n'avais jamais entendu parlé de CSP et l'event loop du JavaScript me paraissait très bien pour ça. J'ai d'ailleurs fait du EventMachine (une sorte d'event loop pour Ruby) dans les années qui ont suivi.
  - Confiance dans le code : j'étais sûrement jeune et naïf, mais je ne me voyais pas utiliser des structures immutables ou du typage statique fort à la haskell (trop contraignant au quotidien pour développer rapidement).
  - Outils : le contexte a tellement changé de ce côté là en 10 ans. Jamais, je ne me serais plaint d'avoir trop d'outils ou qu'ils soient trop complexes en JS il y a 10 ans.
  - Écosystème : nodejs et npmjs n'existaient pas en 2005, jquery et ses nombreux plugins non plus. Pouvait-on prévoir que cela allait devenir un tel bordel ?
  - Complexité du langage : ça se discute. Mais j'ai l'impression que c'est quand même récent que la spec de JavaScript grossit rapidement et deviendra bientôt aussi épaisse que celle du C++.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.