Il manque un langage dans ta liste, Clojurescript. Fonctionnel, élégant, concis, lisible. Certes c'est un dérivé de lisp et donc est plein de parenthèses.
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.
C'est un des points que j'apprécie vraiment le moins aujourd'hui dans le monde javascript. Ok, avant il y avait des callbacks et c'était pas terrible. Mais ce qu'on fait aujourd'hui avec les promises n'est pas tellement mieux, au prix d'une lourdeur d'écriture et de, en général, une difficulté à avoir quelque chose de proprement testable. Certes async/await va dans le bon sens, mais il y aura encore des Promises.
Dans mon taff je bosse parfois sur un projet basé sur Electron. Au final nous avons choisis de faire un backend Go et un frontend à base de clojurescript. Tellement plus agréable. Et l'utilisation de core.async répond tellement mieux à la gestion asynchrone que les promises que ça donne encore moins envie d'aller voir du côté de javascript "classique".
Ok, en brut comme ça c'est pas simple et ça nécessiterait un article entier (à venir) mais pour faire simple j'ai deux requêtes asynchrones, la deuxième dépendant du résultat de la première. Et pourtant je l'ai écrit quasiment comme si c'était synchrone, à part go et <!.
# Clojurescript
Posté par CrEv (site web personnel) . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 3.
Il manque un langage dans ta liste, Clojurescript. Fonctionnel, élégant, concis, lisible. Certes c'est un dérivé de lisp et donc est plein de parenthèses.
C'est un des points que j'apprécie vraiment le moins aujourd'hui dans le monde javascript. Ok, avant il y avait des callbacks et c'était pas terrible. Mais ce qu'on fait aujourd'hui avec les promises n'est pas tellement mieux, au prix d'une lourdeur d'écriture et de, en général, une difficulté à avoir quelque chose de proprement testable. Certes async/await va dans le bon sens, mais il y aura encore des Promises.
Dans mon taff je bosse parfois sur un projet basé sur Electron. Au final nous avons choisis de faire un backend Go et un frontend à base de clojurescript. Tellement plus agréable. Et l'utilisation de core.async répond tellement mieux à la gestion asynchrone que les promises que ça donne encore moins envie d'aller voir du côté de javascript "classique".
Ok, en brut comme ça c'est pas simple et ça nécessiterait un article entier (à venir) mais pour faire simple j'ai deux requêtes asynchrones, la deuxième dépendant du résultat de la première. Et pourtant je l'ai écrit quasiment comme si c'était synchrone, à part
goet<!.