Discussion :

[Michael Guilloux]

JSweet : un transpileur open source de Java à JavaScript
Pour construire des applications JavaScript en utilisant vos compétences en Java

Avec le désir d’offrir aux développeurs Java une approche simple et légère pour créer des applications web, le développeur Renaud Pawlak, CEO de Cincheo, une société de logiciels basée à Paris, a conçu et rendu open source une technologie baptisée JSweet. JSweet est un transpileur de Java à JavaScript via TypeScript. Pour rappel, un transpileur ou un compilateur source à source est un type de compilateur qui prend le code source d'un langage de programmation et le compile dans un autre langage de programmation. Un transpileur opère sur deux langages avec approximativement le même niveau d'abstraction, alors qu'un compilateur traditionnel compile un langage de haut niveau vers un langage de bas niveau.

JSweet est construit au-dessus de TypeScript, le langage de programmation libre et open source développé par Microsoft, et qui est un surensemble de JavaScript. D’après sa description sur son site officiel, « JSweet exploite TypeScript pour vous apporter la façon la plus sûre et la mieux typée de programmer des applications JavaScript en utilisant le langage et les outils Java ». La construction de JSweet au-dessus de TypeScript permet en effet d’amener les toutes dernières API JavaScript dans le monde Java. En d’autres termes, il permet aux développeurs de se reposer seulement sur leurs compétences en Java pour construire des applications web en JavaScript.

Si le code JavaScript peut être utilisé avec TypeScript, ce n’est toutefois pas le cas avec JSweet, vu que les API et la sémantique Java et JavaScript sont trop différentes. Pour décrire JSweet, Pawlak explique que sa technologie fait le même travail que TypeScript, mais pour Java.

Une autre précision importante concernant ce transpileur open source est que « JSweet n’est pas Java », a-t-on signalé sur GitHub. Il utilise seulement sa syntaxe ainsi que les API et programmes exécutés en JavaScript. Autrement dit, avec JSweet, vous pouvez profiter des outils Java pour programmer des applications JavaScript en utilisant les toutes dernières bibliothèques JavaScript. En ce qui concerne les bibliothèques JavaScript, il faut noter qu’elles sont disponibles en Java grâce à l'API Translator Tool de JSweet.

Parmi les caractéristiques de ce nouveau transpileur open source, on peut citer les suivantes :

• une correspondance complète de la syntaxe entre Java et TypeScript, y compris les classes, les interfaces, les types fonctionnels, les types union, les types tuple, les types object, les types string, etc. ;
• plus de 1000 bibliothèques JavaScript bien typées disponibles à partir de Java, des frameworks et des plug-ins pour écrire des applications web et mobiles HTML5 (JQuery, Underscore, Angular, Backbone, Cordova, Node.js, et bien plus encore) ;
• un plug-in Eclipse pour une installation et une utilisation faciles ;
• une facilité d’utilisation de JSweet à partir de n’importe quel EDI ou depuis la ligne de commande ;
• un mode de débogage pour permettre le débogage du code Java au sein du navigateur de votre choix ;
• un ensemble d’exemples web et mobile HTML5 pour commencer à utiliser et vous habituer à JSweet et les API JavaScript les plus communes ;
• un support pour les modules JavaScript (commonjs, amd, umd). Les programmes JSweet peuvent fonctionner dans un navigateur ou dans Node.js ;
• un support pour différentes versions cibles d’ECMAScript (ES3 à ES6) ;
• un support pour les bundles pour exécuter les programmes générés dans la manière la plus simple.

Démarrer avec JSweet

Sources : GitHub, Page officielle JSweet

Et vous ?

Que pensez-vous de ce nouveau transpileur ?
Quelles facilités pourrait-il apporter ?
Quelles seraient ses limites ?

Voir aussi

Forum Java

[tchize_]

Quelle est la différence avec gwt?

[yann2]

Bonjour

Quelle est la différence avec gwt?

Il y a un tableau comparatif avec GWT/Vaadin et DukeScript sur la page d'accueil de l'outil, donnée en lien de l'article.

[koyosama]

Je ne comprends pas pas pourquoi les gens apprennent tout simplement pas le Javascript tout simplement.
Surtout que si vous le temps d'apprendre JsSweet alors vous avez le temps d'apprendre Javascript.

Au meme d'apprendre directement TypeScript.

[ShaeOuloul]

Je ne comprends pas pas pourquoi les gens apprennent tout simplement pas le Javascript tout simplement.

Très bonne remarque, il est en fait plus simple de faire du Javascript directement. Mais ce que j'ai compris de JSweet, c'est qu'il apporte en fait toute la robustesse d'un langage compilé (comme TypeScript) par rapport à Javascript ou tout est interprété, ou la complétion dans les IDEs est encore assez basique, et ou les outils de refactoring sont quasi inexistants. En fait, je trouve que cette techno, tout comme TypeScript, CoffeeScript apporte du professionnalisme à une technologie en vogue. De plus, on bénéficie de tout l'outillage de l'écosystème Java (Maven, Eclipse, Ant, Gradle etc...)
Je pense que cette techno est plus une techno d'entreprise, bien que je l'ai utilisée pour moi et que ca ait très bien fonctionné pour un petit projet.

[adiGuba]

Salut,

Je ne comprends pas pas pourquoi les gens apprennent tout simplement pas le Javascript tout simplement.
Surtout que si vous le temps d'apprendre JsSweet alors vous avez le temps d'apprendre Javascript.

Au meme d'apprendre directement TypeScript.

On pourrait dire la même chose avec TypeScript : pourquoi l'apprendre au lieu de faire directement du JavaScript ?


Sinon JsSweet c'est du Java, donc il n'y a pas vraiment d'apprentissage spécifique pour un développeur Java (autre que les APIs qu'il apporte, mais c'est la même chose pour toutes les librairies qu'on utilise).


Je ne connais pas JsSweet mais GWT qui propose à peu près la même chose, et l'intérêt justement c'est de ne pas avoir à écrire du JavaScript (ou très peu), et de pourvoir utiliser un langage plus robuste car fortement typé (entre autre).

Car dès qu'on fait du Web on n'a pas vraiment de choix pour la couche client : on est obligé d'utiliser du JavaScript.
Les autres solutions apportant beaucoup trop de contrainte...


Et le JavaScript a beau avoir des qualités, il a aussi beaucoup de défauts qui peuvent vite devenir complexe dans de grosse application...

Il y a un tableau comparatif avec GWT/Vaadin et DukeScript sur la page d'accueil de l'outil, donnée en lien de l'article.

Au passage il y a une grossière erreur car ils disent que GWT s'exécute seulement sur le serveur... alors qu'il s'exécute aussi sur le client.


a++

[tchize_]

Je ne comprends pas pas pourquoi les gens apprennent tout simplement pas le Javascript tout simplement.

N'imagine pas que parce que l'on fait des choses comme GWT on ne fait pas de javascript. Mais quand je compare le dev de l'application en javascript et le dev de l'application avec angularJS (ben oui on a les deux au boulot), je trouve le dev GWT bien plus confortable et efficient en termes de temps de développement. L'utilisation d'un language fortement typé comme java permet de détecter énormément de choses à la compilation. Le développement JS, c'est travailler au marteau et au ciseau à bois. Certe c'est joli et propre à l'arrivée, mais dans la plupart des cas, sortir la défonceuse et la scie à ruban, c'est bien plus efficace.

Et surtout, des trucs comme GWT, ça permet d'avoir des objets qui sont les mêmes entre le code serveur et le code client, pour tout ce qui est DTO, ce n'est pas négligeable. Avec du pur javascript, on doit coder chaque DTO deux fois, on doit faires tous les changements à deux endroits...

Pour le tableau de comparaison GWT / JSweet, je l'ai vu, mais je ne vois pas où l'auteur a vu qu'on ne savait pas utiliser les milliers de farameworks JS existant en GWT, ça ne pose pas de soucis.

[adiGuba]

Pour le tableau de comparaison GWT / JSweet, je l'ai vu, mais je ne vois pas où l'auteur a vu qu'on ne savait pas utiliser les milliers de farameworks JS existant en GWT, ça ne pose pas de soucis.

En fait c'est juste qu'ils proposent des librairies Java pour ces frameworks, permettant de les utiliser directement avec JSweet sans rien faire de spécial :
https://jsweet.org/apidocs/releases/org/jsweet/candies/
https://jsweet.org/apidocs/snapshots...sweet/candies/

Après même le lien semble meilleur qu'avec GWT puisqu'il n'y a pas à écrire de code JavaScript (tout est fait via des déclarations/annotations).
Là où avec GWT c'est un peu plus "complexe" pour l'instant car il faut le faire à la main avec JSNI et du code JavaScript.


Mais du peu que j'en ai vu, cela semble fonctionner un peu de la même manière que JS Interop de GWT 2.8...


[edit] L'autre gros avantage de JSweet (et de JS Interop de GWT 2.8), c'est qu'il est possible d'écrire en Java des classes qui serait utilisable directement en JavaScript.

a++

[renaudpawlak]

Hello adiGuba,

En tant que créateur de JSweet, je me permets de réagir à ton analyse, qui est à la fois tout à fait exacte, mais mérite aussi d'être complétée

Oui, GWT et JSweet n'ont rien à voir. Mais j'ai eu tellement de personnes qui m'ont demandé en quoi JSweet différait de GWT (et qui ne comprenaient pas la différence) que j'ai bien du essayer de l'expliquer. Ce genre de comparatif n'a pas pour objectif d'être universel, mais de mettre en avant les différences fondamentales. Je l'affine jour après jour en prenant en compte l'opinion des gens, mais JSweet n'étant en ligne que depuis un petit mois, c'est encore loin d'être parfait.

Comme l'explique maintenant la première ligne de mon comparatif, JSweet est un transpiler, alors que GWT est un framework (qui intègre un transpiler). JSweet, c'est exactement comme TypeScript, mais pour Java, alors que GWT vient avec toute une mécanique pour créer des applis client-serveur avec un SDK propre à GWT. JSweet est très light (moins de 40.000 lignes de code, encore mois si on enlève les tests) alors que GWT, c'est un gros logiciel (>600.000 lignes de code il me semble). Donc, oui, si tu veux, tu peux dire que GWT va beaucoup plus loin, mais en réalité je pense que ce n'est pas tout à fait juste de dire cela car en réalité c'est juste que les approches, les philosophies, et les objectifs sont radicalement différents.

GWT a poursuivi pendant des années le Graal de prendre du code Java avec des APIs Java et de l'exécuter sur le WEB. C'est un objectif louable et enthousiasmant, mais qui mène à un framework complexe et qui présente un grand nombre de désavantages:

1. C'est très lourd (désolé... je n'aime pas la critique).
2. Quand tu commences faire du GWT, tu utilises leur SDK et tu te retrouves donc enfermé dans des APIs et une logique spécifique.
3. Comme tu n'as pas accès aux APIs JS, toutes les dernières avancées des frameworks JS (AngularJS, KnockoutJS, ThreeJS, Node.js, Three.js, D3.js, etc, etc) ne te sont pas accessibles (ou très difficilement).
4. Comme le code généré préserve la sémantique du langage Java, cela donne un code généré pas toujours simple à débugger dans un browser même avec les source maps... au contraire JSweet étant "WYSIWYG", tous les éléments du code Java se retrouvent dans le browser, y compris les variables que tu peux accéder via la console par exemple. La stacktrace est fidèle à ton fil d'exécution et reflète ton code source Java original. Comme en TypeScript donc, c'est facile de s'y retrouver.

JSweet est donc beaucoup plus proche de TypeScript/JavaScript. Quand tu veux faire une appli client-serveur, tu peux tout à fait utiliser un serveur Java ou un serveur Node.js, et tu es totalement libre de l'architecture que tu souhaites utiliser. Tu peux facilement partager des Data Objects entre le programme JSweet (JavaScript client-side) et Java (server-side) car ils vont compiler aussi bien dans l'un ou l'autre contexte.

Oui, en JSweet, tu ne peux pas utiliser les API Java. Donc effectivement, la question de pourquoi ne pas utiliser TypeScript est légitime. La réponse pour moi est très claire: c'est comme vous voulez. Les deux marcheront aussi bien, sauf que dans le cas de JSweet, les développeurs se retrouveront dans un environnement Java, avec un tooling Java et avec 90% des concepts et du langage qu'ils connaissent déjà. Par exemple un développeur Java programmant une appli Node.js n'aura pas à connaitre les "require" de commonjs, mais pourra simplement faire des imports Java, comme il a l'habitude de le faire (et son IDE favori pourra lui faire automatiquement en fonction des APIs qu'il souhaite utiliser). Il est clair pour moi qu'un développeur JavaScript ira préférentiellement vers TypeScript car c'est un superset et qu'il a l'habitude du tooling. Mais un développeur Java aura le choix, et sans aucun risque car le code généré est très lisible, ce qui permettra de switcher sur TypeScript si nécessaire.

Last but not least, je tiens à signaler que JSweet est le premier projet au monde à avoir traduit l'ensemble des API JavaScript DefinitelyTyped en Java, soit des centaines d'API JS. En ce sens, JSweet est allé BEAUCOUP plus loin que GWT! En réalité JSweet et GWT pourraient être complémentaires car GWT serait très content de pouvoir bénéficier de ces APIs...

Voilà. J'espère que ces précisions permettront de clarifier les esprits et surtout d'expliquer pourquoi mon tableau comparatif pose autant de problème aux gens. Oui, il est potentiellement polémique de prime abord, mais il est là pour faire comprendre aux gens que les philosophies sont radicalement différentes et qu'il ne s'agit en aucun cas d'un clone de GWT. Je l'améliore de jour en jour

Cheers!

[adiGuba]

Salut renaudpawlak,


Je ne remet pas en cause JSweet ou ses qualités.

C'est vraiment la comparaison qui est foireuse. C'est comme si tu comparais un pneu à une voiture... et au final cela te dessert plus qu'autre chose.

Pour avoir une comparaison valide il faudrait que ce comparatif prennent également en compte les possibilités offerte par GWT, par exemple :

• Pourvoir utiliser une partie de l'API standard Java (dont l'API de Collections : http://www.gwtproject.org/doc/latest...Emulation.html)
• Pourvoir utiliser n'importe quelle librairies Java (à partir du moment où l'on dispose des sources et qu'elle n'utilise pas des API non-supporté)
• Pourvoir partager du code métier entre le client et le serveur (et pas seulement des Data Objects).
• Pourvoir bénéficier de stacktraces mappé vers le code Java "autant que possible" (selon le navigateur).
• Bénéficier des optimisations du compilateur (en particulier la suppression du code mort et la résolution des constantes à la compilation)

De plus, outre le fait qu'il manque beaucoup d'éléments, le comparatif reste un peu biaisé sur les autres points

• Node.js support : Techniquement c'est possible de l'utiliser avec GWT (il y a d'ailleurs un vieux projet là dessus : gwt-node).
  C'est juste qu'il n'y a pas trop d'intérêt puisque c'est exactement la philosophie inverse de GWT (pourquoi vouloir utiliser Java sur le client, et JavaScript sur le serveur !)
• Code Execution : GWT est sur "It depends" alors qu'il permet de vraiment exécuter du code sur le client ET sur le serveur.
  JSweet est sur "Can do both" alors qu'il permet seulement d'exécuter du code sur le client, et simplement de partager des Data Objects avec le serveur.
• Native in-browser Java debugging : Pourquoi est-ce "less native" ? Tu parles bien de SourceMaps ?
  Avec GWT il fournit bien le code initial (en mode dev seulement bien sûr).
• Available well-typed Java libraries : tu oublies de préciser que l'on peut ajouter n'importe quel librairie à partir du moment où l'on définit ses wrappers.
  La seule différence c'est que ce n'est pas fournit par GWT lui-même. Il faut soit écrire le wrapper soit-même, soit trouver une librairie toute faite
  Or tu laisses entendre que ce n'est pas possible...

Sinon concernant tes 4 points :

1. GWT est certainement plus lourd à mettre en place et le build est un peu long, mais c'est tout aussi performant à l'exécution.
2. faux : tu peux très bien faire du GWT en te contentant d'utiliser le compilateur, sans utiliser leurs API ou logique (je le fais déjà partiellement).
3. faux : j'utilise plusieurs librairies JavaScript sans aucun problème.
4. faux : SourceMaps fonctionne avec GWT, avec une association 1-1 vers le code source Java correspondant.



Si je dis tout cela, ce n'est pas pour "casser" JSweet ou autre. Au contraire...
Le comparo avec GWT semble placer JSweet comme une solution alternative bien meilleure et proposant plus de fonctionnalité... mais c'est deux technos tellement différentes qu'il n'en est rien (et du coup la déception est encore plus grande).

Last but not least, je tiens à signaler que JSweet est le premier projet au monde à avoir traduit l'ensemble des API JavaScript DefinitelyTyped en Java, soit des centaines d'API JS. En ce sens, JSweet est allé BEAUCOUP plus loin que GWT! En réalité JSweet et GWT pourraient être complémentaires car GWT serait très content de pouvoir bénéficier de ces APIs...

En clair tu as conçus un convertisseur qui transforme les fichiers .d.ts en .java afin de pouvoir les utiliser directement sans rien toucher.
Très astucieux ! Je me demandais comment tu avais pu proposer autant de librairies si rapidement...


a++

[renaudpawlak]

Je sais bien que GWT permet d'écrire des wrappers pour accéder aux API JavaScript, mais je considère que si chaque programmeur doit les écrire à la mano, il s'agit d'un boulot titanesque et comme JSweet le propose en standard, il me semble honnête de dire que GWT ne propose pas les APIs en standard.

Je sais aussi que tu peux faire du GWT sans utiliser les APIs GWT, mais dans ce cas, tu sors du framework initial. C'est un peu biaisé aussi il me semble de dire que GWT c'est léger alors que tu as du batailler et entrer dans les entrailles du framework pour n'en utiliser que le quart non?

De la même manière, je ne suis pas allé regarder de près GWT avec Node.js, mais clairement, comme tu le dis toi même, cela va contre la philosophie du projet. Est-ce vraiment GWT ou encore une manière de récupérer une partie de GWT pour faire ce pour quoi il n'a pas été prévu à la base? Est-ce au moins dans la doc officielle? Honnêtement, avec JSweet, c'est super natif de faire du Node.js... (voir https://github.com/lgrignon/jsweet-node-example).

Au final je pense qu'effectivement, GWT cherche à faire tellement de choses qu'on peut le détourner pour faire autre chose que GWT. Mais la question que je pose: est-ce-vraiment encore du GWT? Si je commence à mettre tout ce qu'on "saurait faire" en mode non standard avec GWT, alors il me faudrait un tableau de 2 pages et il y aurait du vert partout. Ce ne me semble pas bien non plus.

A mon avis un projet se doit d'avoir une ligne directrice claire et un focus lisible et simple pour ses utilisateurs. A mon avis, GWT veut trop en faire. On ne peut pas à la fois avoir les bénéfices de Java et de JavaScript, le tout dans un projet simple... c'est une utopie. C'est comme si on avait ajouté du code C directement dans du code Java plutôt que de faire JNI. A un moment, il faut séparer les préoccupations, modulariser les problèmes.

Tout ceci étant dit, je comprends bien ton point et je vais le prendre en compte. J'apprécie ta perspicacité:

En clair tu as conçus un convertisseur qui transforme les fichiers .d.ts en .java afin de pouvoir les utiliser directement sans rien toucher.
Très astucieux ! Je me demandais comment tu avais pu proposer autant de librairies si rapidement...

Tu as quasiment tout compris à JSweet!

[adiGuba]

Le problème c'est que tu compares JSweet à GWT, avec un comparatif qui met plein d'avantages et de fonctionnalités à JSweet en ignorant totalement les avantages de GWT.

Du coup au premier regard on croit trouver une alternative à GWT en mieux.
Mais en fait c'est pas çà du tout déception...

Cela te dessert car la comparaison avec GWT attirera les utilisateurs de GWT, et la première chose qu'ils remarqueront c'est tout ce qu'ils ne pourront plus faire...



a++

PS : Pour Node.js la remarque vaut aussi pour JSweet : pourquoi vouloir écrire du Java qui tournera sur du JavaScript lorsqu'on peut faire du Java qui tournera sur une JVM...

[tchize_]

@renaudpawlak je serait tenté de tester ça au boulot sur une webapp de type angular.js et actuellement préparée avec une combinaison de ant + npm. As-tu une doc sur comment lancer la transcompilation à la main, que j'en fasse une target ant?

[ultraboa]

Cette techno parait intéressante mais aussi très proche de ST-JS, quelqu'un saurait-il expliquer la différence entre les 2 ?

J'ai commencé à utiliser TeaVM un autre transpileur plus proche de GWT dans le sens où il émule l'environnement Java (enfin une partie) mais avec la différence qu'il prend le byte code en entrée et non le code source (ce qui lui permet de fonctionner aussi avec d'autres langages de la JVM). Il est encore assez peu connu mais je le trouve très bien et surtout beaucoup plus rapide à compiler que GWT (son principal reproche).

Il serait peut-être intéressant de faire cohabiter ces 2 approches, par exemple partager dans un premier temps la logique applicative commune entre un backend java et un frontend web grâce à GWT ou TeaVM, puis compléter l'application web par JSweet ou ST-JS pour l'intégrer dans un framework web tel que Angular ou autre.

C'est ce que je compte faire pour mon prochain projet. Si quelqu'un a déjà fait un tel choix de conception, je suis intéressé par son retour d'expérience

[renaudpawlak]

@ultraboa: effectivement c'est très très proche de ST-JS. Si proche que nous sommes actuellement en discussion pour voir si une alliance serait envisageable.

Concernant les différences (point de vue forcément un peu pro-jsweet )...

1. JSweet propose en standard quasiment toutes les librairies JavaScript bien typées, via une traduction des APIs TypeScript de DefinitelyTyped. Par exemple, c'est possible d'utiliser Angular avec toutes ses extensions mais aussi plus de 1000 librairies (voir http://www.jsweet.org/candies-snapshots/). ST-JS permet aux programmeurs d'écrire leurs propres bridges et vient avec une dizaine de libs sous maven, mais la communauté étant sans commune mesure avec celle de TypeScript il n'y a vraiment à mon avis aucune comparaison possible entre la quantité et la qualité des APIs fournies par JSweet. De ce point de vue là, je conseille vivement (et objectivement) d'utiliser JSweet, un transpiler sans les APIs ne permettant pas de tirer partie de toute la puissance de JavaScript.

2. JSweet passe par TypeScript pour compiler contrairement à ST-JS qui compile directement en JavaScript. Avantage à ST-JS en terme de performance a priori (info non vérifiée), mais avantage à JSweet en terme de fiabilité et de flexibilité. En effet, JSweet recompile le code généré via TypeScript ce qui permet une double vérification et garantie que le code JavaScript généré est de la même qualité que le code généré par TypeScript (ce qui n'est pas rien). Grâce à TypeScript, JSweet est capable de générer du code compatible de ES3 à ES6 et de gérer les modules AMD, UMD et commonjs (Node.js)... Accessoirement l'autre avantage est de pouvoir éventuellement avoir facilement des équipes mixtes JSweet (Java) / TypeScript.

3. ST-JS propose un plugin Maven plus élaboré. Le plugin Maven JSweet est plus basique. Par contre JSweet propose un plugin Eclipse.

4. ST-JS propose en standard un support pour les tests unitaires. JSweet aussi supporte les tests unitaires mais clairement moins aboutis pour l'instant, ce qui demandera pour les utilisateurs un peu plus de travail à mettre en place (mais c'est possible bien évidemment).

Voilà, j'espère ne pas avoir été trop biaisé dans cette comparaison.

Concernant l'architecture que tu mentionnes, je ne connais personne qui ne l'ai encore essayée. Par contre on a plusieurs exemples qui utilisent angular (pour inspiration peut-être):

- https://github.com/cincheo/jsweet-ex...s/Angular.java
- https://github.com/lgrignon/jsweet-node-example

La RC1 JSweet doit sortir début janvier. Un timing idéal pour le tester sur un vrai projet