URL: https://linuxfr.org/users/nono/journaux/et-si-javascript-allait-droit-dans-le-mur Title: Et si JavaScript allait droit dans le mur ? Authors: Bruno Michel Date: 2016年03月02日T20:55:55+01:00 License: CC By-SA Tags: langage, javascript, pony, elixir, es6, js-fatigue et elm Score: 78> 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, ces 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érimental, mais de temps à autre, un langage perce. Ce fût 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é. Celui 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 _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 15 ou 20 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é nodejs, 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 Open-Source. ### 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 être notre seul moyen d'avoir confiance dans le code que l'on écrit. D'ailleurs, les autres langages cités au-dessus 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'IDE, 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 plugins 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 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. Ensuite, il y a tous ces plugins 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 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](https://twitter.com/jashkenas/status/704399369051770880). Mais ce qui est sûr 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 によって変換されたページ (->オリジナル) /