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

Le , par Michael Guilloux, Chroniqueur Actualités
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


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de tchize_ tchize_ - Expert éminent sénior https://www.developpez.com
le 19/12/2015 à 8:55
Quelle est la différence avec gwt?
Avatar de yann2 yann2 - Membre expérimenté https://www.developpez.com
le 19/12/2015 à 10:10
Bonjour

Citation Envoyé par tchize_  Voir le message
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.
Avatar de koyosama koyosama - Membre éclairé https://www.developpez.com
le 19/12/2015 à 10:56
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.
Avatar de ShaeOuloul ShaeOuloul - Futur Membre du Club https://www.developpez.com
le 19/12/2015 à 11:43
Citation Envoyé par koyosama  Voir le message
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.
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 19/12/2015 à 12:42
Salut,

Citation Envoyé par koyosama  Voir le message
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...

Citation Envoyé par yann2  Voir le message
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++
Avatar de tchize_ tchize_ - Expert éminent sénior https://www.developpez.com
le 19/12/2015 à 12:49
Citation Envoyé par koyosama  Voir le message
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.
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 19/12/2015 à 13:27
Citation Envoyé par tchize_  Voir le message
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++
Avatar de ShaeOuloul ShaeOuloul - Futur Membre du Club https://www.developpez.com
le 19/12/2015 à 13:52
Merci adiGuba, c'est exactement ça. Pour ma part je n'ai jamais utilisé GWT mais je l'ai vu utilisé, et j'ai contribué à JSweet dernièrement. En fait, l'avantage de JSweet c'est effectivement que tu utilises la syntaxe Java, mais la légèreté de de Javascript, toutes les librairies sont utilisables directement dans le code Java et il n'y a rien à faire tourner c'est une simple transpilation.
Je ne sais pas pourquoi l'auteur, Renaud Pawlak a précisé que GWT ne tournait que coté serveur, mais je pense que c'est une erreur.

Dans tous les cas, comme pour GWT, JSweet permet le partage du code entre le client et le serveur, mais le but premier et la robustesse et la légèreté. Il y a d'autres articles qui discutent de la différence entre JSweet et GWT c'est assez intéressant par exemple https://news.ycombinator.com/item?id=10737058
D'ailleurs on constate que c'est Renaud Pawlak qui a répondu en personne donc les réponses seront surement plus pertinentes que les miennes

Je vais essayer de faire un Live sample pour JSweet, pour que Renaud l'intègre au site.

Bye!
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 20/12/2015 à 9:23
J'ai regardé d'un peu plus près JSweet, et la comparaison avec GWT est faussée et dessert même JSweet tant les deux n'ont pas grand chose en commun.

JSweet permet d'écrire son code dans le langage Java... mais cela s'arrête là : tout cela reste du JavaScript/TypeScript.
Du coup je comprend mieux la remarque de koyosama : autant faire du TypeScript directement...

GWT va beaucoup plus loin que cela, en implémentant un grande partie de l'API Java, ce qui permet d'importer un très grande nombre de librairies Java (à partir du moment où l'on dispose du code source), ou de partager du code entre le serveur et le client.
Sans oublier que GWT propose plein d'API permettant de simplifier le développement d'une webapp...

a++
Avatar de renaudpawlak renaudpawlak - Membre à l'essai https://www.developpez.com
le 21/12/2015 à 12:04
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!
Contacter le responsable de la rubrique Accueil