URL: https://linuxfr.org/news/et-si-javascript-allait-droit-dans-le-mur Title: Et si JavaScript allait droit dans le mur ? Authors: Bruno Michel Davy Defaud, Pierre Jarillon et patrick_g Date: 2016年03月04日T11:05:54+01:00 License: CC By-SA Tags: crystal, pony, oden, elm, elixir, javascript et js-fatigue Score: 37 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](https://golang.org/), [OCaml](https://ocaml.org/), [ClojureScript](https://github.com/clojure/clojurescript), etc. Enfin, on peut également retrouver un certain espoir avec [WebAssembly](https://hacks.mozilla.org/2015/12/compiling-to-webassembly-its-happening/) (le successeur d’_asm.js_), qui permettrait à de nombreux langages d’être compilés vers la plate‐forme Web. ---- [Journal à l’origine de la dépêche](http://linuxfr.org/users/nono/journaux/et-si-javascript-allait-droit-dans-le-mur) [Crystal](http://crystal-lang.org/) [Pony](http://www.ponylang.org/) [Oden](http://oden-lang.org/) [Elm](http://elm-lang.org/) [Elixir](http://elixir-lang.org/) ----> _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](http://crystal-lang.org/) 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](http://www.ponylang.org/) 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](http://oden-lang.org/) 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](http://elm-lang.org/) 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](http://elixir-lang.org/) 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](https://fr.wikipedia.org/wiki/Communicating_sequential_processes) 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_](https://tc39.github.io/ecmascript-asyncawait/). 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](http://elm-lang.org/blog/compilers-as-assistants) : 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](http://www.wtfjs.com/), 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_](https://golang.org/cmd/gofmt/), pour formater le code d’une manière standard. Je ne suis pas un utilisateur d’[EDI](https://fr.wikipedia.org/w/index.php?title=Environnement_de_d%C3%A9veloppement&redirect=no "Environnement de développement intégré"), mon [Neovim](https://neovim.io/) 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](https://fr.wikipedia.org/wiki/Sass_%28langage%29 "Syntactically Awesome Stylesheets") 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_](https://www.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_](https://www.npmjs.com/package/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_](https://lodash.com/docs#pick) ou [_debounce_](https://lodash.com/docs#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_](https://www.npmjs.com/package/rimraf) et [_del_](https://www.npmjs.com/package/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](https://twitter.com/jashkenas/status/704399369051770880). 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](https://github.com/wycats/javascript-decorators/blob/master/README.md) des [observables](https://github.com/zenparsing/es-observable) et des [symboles](https://github.com/medikoo/es6-symbol). 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 ?

AltStyle によって変換されたページ (->オリジナル) /