Bonjour,

Je suis de ceux qui pense qu'on ajoute bien trop de choses à EcmaScript et plus qu'un JS++ je préfèrerais un JS--

Mais je comprends aussi le besoin de langages plus fortement typés, comme le sont Dart ou TypeScript.

Il y a en général au moins deux points qui font qu'on recherche à changer JS pour ce qu'il n'est pas.
Le premier, c'est de retrouver l'équivalent de la phase de compilation des langages comme Java ou C pour détecter au plus tôt les erreurs éventuelles. Alors qu'avec un interprète c'est à l'exécution que l'on trouve l'erreur.
Le deuxième est la notion de classe qui force est de constater est une chose sinon maitrisé tout au moins connue de la grande majorité. Alors que la notion de prototype l'étant beaucoup moins demande une adaptation, voire un apprentissage important. Je pense que l'ajout à EcmaScript de l'opérateur new et du mot clef classe et autre bricole ne fait qu'ajouter de la confusion.

J'ai donc regardé ce qui se fait pour répondre à cette demande. On peut de suite mettre dans le lot tous les langages compilés qui produisent du JavaScript. Objective-J, Dart, TypeScript, CofeeScript, JavaScript++ ....

Comme je le disais en début d'article je suis un adepte de JS--. Alors j'ai regardé ce qu'il se faisait pour allier les deux aspects.

En premier lieu TypeScript dont le compilateur produit du code JS qui au final n'utilise qu'un sous-ensemble de JS (pas de new pas de classes, etc.) le compilateur pour une définition de classe Typescript va produire un prototype JavaScript don la définition est faite dans une closure. Simple propre efficace, sans fioritures.
Le transtypeur (compilateur) est lui-même écrit en TypeScript et produit donc un JavaScript qui est exécuté par nodeJS. (ou embarqué dans l'application)

Ensuite non pas un langage, mais un outil : JSweet le but de celui-ci est de proposer un développement web en utilisant un langage grandement enseigné => Java. Il existe pour cela beaucoup de choses, mais nous parlons là de JavaScript. Il ne s'agit donc pas de faire du Web traditionnel comme avec tapestry, Struts et autre JEE tools. Il s'agit de compiler des classes Java en JavaScript.
JSweet n'est donc pas Java, mais seulement la syntaxe Java pour tout le reste c'est du côté JS qu'il faut chercher. La difficulté est que lorsqu'on développe une application JS on fait appel a quantité d'éléments prédéfinis. Côté client le DOM, les Objets standards que sont Date et Math par exemple... Pour rendre la compilation cohérente, il est nécessaire d'avoir ces références accessibles. De même si on veut pouvoir éditer correctement il nous faut les définitions de ces éléments. JSweet est un projet qui utilise Maven (ce n'est pas obligatoire, mais ça facilite) un grand nombre de librairies ont été packages pour être disponible : les candies.
Ces Candie ont quelque chose d'intéressant et pas seulement pour JSweet. Le compilateur JSweet se fait en deux étapes. De java vers TypeScript puis TypeScript vers JavaScript. L’avantage est de bénéficier des avancer du compilateur TypScript, mais aussi de sa bibliothèque. Une Candie est un Jar qui contient la définition Java, et TypScript de la librairie. Ainsi on trouve une Candie JQuery qui permet de l'utiliser en JSweet, mais aussi le TS qui va avec. Les Candies sont nombreuses et dans de nombreuses versions. Les jar sont ici http://repository.jsweet.org/artifac...sweet/candies/ par exemple angular-1.5.0-1.1.0-20160525.jar contient angular.d.ts ainsi que le code java correspondant. C’est donc une bonne source pour qui cherche une définition d'une lib JS pour l'utiliser avec TypeScript. L’outil est opérationnel, mais je ne me prononcerais pas sur son usage pour la production.

Un autre outil autour de TypeScript : typescript-xtext xtext est une techno éclipse destinée à créer des DSL (Domain Specific Language) Le POC, est comme son nom l'indique une démo de faisabilité. xtext est un outils java qui va permette de produire un éditeur éclipse (mais aussi pour d'autres IDE) et un Générateur de code. Ce projet bien qu'incomplet démontre qu'il est possible de créer un compilateur TypeScript to JS en Java. Le projet n'est pas assez avancé pour le rendre utilisable. Il laisse entrevoir une issue pour tous les projets dont la chaine de production passe par Maven ou Gradle et qu'ils n'utilisent pas de gulp, grunt, nodeJS. En effet en étant full Java
Les outils Maven, Gradle sont autosuffisant.

Pour finir une approche totalement expérimentale dont l'objectif est autre: WASM. l'idée de WASM, est de proposer un assembleur pour le web. Ce qui permettrait de compiler le langage de son choix vers wasm et donc de l'exécuter sur le navigateur. Dans la construction d'un tel outil c'est posé la question du langage à compiler vers WASM (avant de s'attaquer au langage commun) c'est ainsi qu'est né ThinScript. Ce langage est proche de TypeScript tout comme TypeScript un compilateur a été écrit. Celui-ci écrit en ThinScript produit un compilateur en JavaScript exécutable avec nodeJS. un "exécutable" wasm, mais il produit aussi un source C qui permet d'obtenir un exécutable natif. Autre particularité intéressante est la réponse apportée à l'absence de disponibilité de WASM. l'assembleur du web n'existant que sur de rares plateformes le compilateur sait produit soit du wasm soit du JavaScript. https://evanw.github.io/thinscript/ (choisissez les options du compilateur pour visualiser le résultat) là encore on constate que le JavaScript produit est un sous-ensemble d'EcmaScript (utilisation des closures et prototype).

Le niveau de maturité des différents projets et très inégal. Mais il semble se dessiner un schéma global.
L’utilisation de chaine de production rapide et efficace (je pense au code natif ou java) et la production de code utilisant un sous-ensemble de JS.
La diversité des voies montre bien qu'il y a une place pour d'autres approches. On voit aussi que le lien avec l'existant n'est pas oublié. Je pense que les Candies de JSweet sont une bonne idée dans le principe. (l'outillage pour les produire peut être encore plus ouvert) un repository à la Gradle Maven, etc. contenant pour chaque lib le fichier .js, le fichier .asm ainsi que les définitions pour les imports dans les principaux langages ts, thin, java, dart etc. faciliterait très grandement la création de chaines de productions automatisées. Je pense entre autres aux contraintes qu'impliquent les mélanges que l'on est obligé de mettre en oeuvre sur certains projets. Une application JEE dont le front est fait avec Angular se retrouve confrontée à une dualité gulp et grunt ne savent pas gérer correctement la partie back. Et Maven ne gère que mal la partie front. Du coup on voit beaucoup de projets avec des mix plus ou moins stables.
Ces différents projets laissent espérer une simplification de ces chaines de production. je pense par exemple à une application dont le front est en Angular2 et le back en C++ un Make pourrait avec une techno similaire au compilateur thin compiler à la fois les classes ts d'angular et les classes C++ du back.
Dans le même genre, un compilateur en java permettrait à Maven Gradle, etc. de se passer de nodeJS.
Et on voit bien que tous gardent la possibilité de s'exécuter avec node se qui ouvre encore des portes.

Pour finir un point qui me parait particulièrement intéressant est la notion de Candie. Cette approche répond à une difficulté rencontrée dans certaines entreprises. Le passage par le proxy. Cela n'a l'air de rien, mais j'ai constaté que ce n'est pas toujours simple de concilier la politique de sécurité et les outils que nous utilisons.
Généralement la situation qui pose problème est la suivante. Les postes des développeurs n'ont accès à internet qu'au travers d'un proxy dont l'authentification est forte. Du coup les outils php gulp grunt etc. ne parviennent pas à travers. J’ai trouvé ça dans les boites qui ont une tradition Java. En java un repository internet est installé et celui-ci sert de frontal. Lorsque un développeur java à besoin d'un jar il le demande au repository qui au besoin ira sur le net le chercher. Les tenants de la sécurité apprécient cette approche, car elle permet de concentrer le point de contact internet sur le repository. Mais dans nos outils JS il faut invoquer de multiples URL pour obtenir tous les éléments. Les Candie apportent l'approche d'identification qu'un package indépendamment de sa localisation. Ce qui permet de mettre en oeuvre ce principe utilisé en java. Reste que les Candie telles quelles sont insuffisantes. En effet elles contiennent les définitions, mais pas la lib correspondante.
Aujourd'hui pour mettre en oeuvre un repositiory interne il faut ajouter chaque lib dans chaque version utilisée à la main sur le serveur local. Mais en plus il faut redéfinir les URL pour que grunt gulp etc. s'adresse au serveur interne.

Après toutes pages que j'ai lues sur le sujet. Je pense que nous ne sommes qu'au début d'un tournant qui ne fait aujourd'hui que se dessiner. Il est bien trop tôt à mon avis pour dire ce qu'il sera.

A+JYT