A la Poursuite du Code en Rouge

Je n’aime pas JavaScript (sous toutes ses formes, ECMA ou ActionScript) alors je suis très chatouilleux quand on critique GWT sous l’angle « c’est quand même mieux avec <nom de son framework JavaScript favori> ». Entendons-nous bien, la panacée n’existe pas, et GWT ne l’est pas. Je trouve simplement que certains arguments entendus ou lus ici et là de la part des tenants du JavaScript sont un peu douteux Petite revue…

Le JavaScript généré par le compilateur GWT est incompréhensible

Je suis d’accord à 100%… mais je ne vois en quoi c’est un problème ! J’ai un aveu vous faire : j’ai fait pas mal de Java jusqu’ici, et je ne suis jamais allé lire le bytecode généré dans mon fichier .class. Honte à moi. Oserai-je l’avouer ? Je ne saurais de toute façon pas lire du bytecode. Curieusement, cela ne m’a jamais empêché d’écrire du Java… 8)

Ça revient à dire qu’il ne faut pas faire de langage C parce-que, eh bien, le langage machine qui est produit en « -O2« , on le comprend pas… Le but du compilateur est justement de générer du code que l’on a pas envie d’écrire à partir d’un langage généralement de plus haut niveau…

Oui, mais, ah aaah ! Et si le compilateur GWT a un bug ? Il faut modifier le code généré !

Je vais même aller plus loin dans votre direction : selon la bonne vieille loi de Murphy, il y a sûrement plusieurs bugs dans le compilateur GWT. Là encore, a-t-on attendu le tout dernier gcc stable pour faire du C ? Je vous mets au défi, quel que soit le langage, de trouver un compilateur qui n’ait jamais eu un bug ! Dans ce cas-là, on triture, on contourne.

Ça serait effectivement hypocrite d’affirmer qu’il n’y a pas de souci parce-que le compilateur est open-source. Qui a vraiment envie d’investir le temps nécessaire à rentrer dans le code interne d’un compilateur ? Moi pas.

La bonne question est plutôt : quel est le risque lié à un bug dans le compilateur GWT ? Voyons voir… Détecter un comportement différent entre le JavaScript généré et le Java sera probablement mis en évidence par un test unitaire (les plus paranoïaques d’entre nous pourront générer également le javascript pour les tests unitaires et les exécuter in situ dans le navigateur). Reste plus qu’à trifouiller un peu le Java jusqu’à trouver une séquence qui compile correctement (vous voyez maintenant pourquoi je vous parlais de test unitaire ). Au pire, (r)écrivez la séquence problématique en JavaScript via JSNI. La probabilité de tomber sur un bug 100% bloquant et/ou souvent sur des bugs de compilation sévères me semble très faible et donc acceptable.

Oui, mais le JavaScript généré sera « sub-obtimal » ! Sûrement pas aussi bien que mon JavaScript finement ciselé !

Premièrement : la loi de Moore. Les navigateurs modernes sont capables d’exécuter de mieux en mieux le JavaScript. La différence supposée de performances est-elle vraiment grave ? Attention à ne pas faire d’optimisation prématurée (« la racine de tous les maux »), le javascript généré suffira-t’il à faire passer la réactivité d’un script de acceptable à non-acceptable par l’utilisateur ?

Deuxièmement, il est possible que le javascript généré par GWT sera bien plus concis :

• Le compilateur essaie de ne conserver que le code réellement appelé. Je peux me constituer une librairie de composants GWT réutilisable entre les projets, le compilo reconnaîtra les siens. Au contraire, les frameworks JavaScripts sont pour la plupart peu modulaires.
• Le code GWT n’ayant pas besoin d’être lu/maintenu, il subit une sorte d’obfuscation lors de la génération de JavaScript, il est bien plus compact que le JavaScript que vous allez écrire. Ou alors vous ne mettez jamais de commentaires et vos noms de fonctions et variables tiennent sur trois caractères . Dans ce cas je vous prierai de quitter ce site immédiatement. Je ne vous salue pas .

Oui, mais mon framework JavaScript fonctionne sur tous les navigateurs

Ça me semble au contraire la meilleures des raisons de faire du GWT : ne plus s’en occuper ! Le code généré essaie tout autant d’être multi-navigateur. A moins que le projet GWT meure, on peut supposer qu’une mise-à-jour du compilateur permettra de simplement recompiler et déployer pour que l’application soit compatible avec tout nouveau navigateur.

Alors tu rejettes en bloc toutes nos critiques ! Tu n’es pas objectif non plus !

C’est vrai, j’adore le principe de GWT

Mais l’implémentation, elle, est critiquable bien sûr. Les remarques pertinentes des javascripteurs sont :

• GWT réussit à peu près bien à encapsuler le DOM, mais échoue (pour l’instant) à encapsuler CSS correctement. Il vaut mieux connaître un minimum de HTML+CSS avant de démarrer un développement GWT : Java n’y suffit pas.
• GWT n’est pas mature. On trouve dans GWT les attributs d’une techno assez jeunes : documentation incomplète, exemples de code tenant lieu de documentation, bugs effroyables dans la librairie, les « c’est pas possible ça a jamais été testé comment ils veulent que ça marche ça ! » et les « j’ai fouillé partout je trouve trop pas la fonction pour …, c’est pas possible, ils ont jamais fait une vraie appli avec leur truc ». Bref, attendez-vous à des surprises en allant plus loin que le « bonjour, monde ». Cet effet est rattrapé en partie par la réactivité du projet, on sent d’une version à l’autre qu’il est bien piloté par les demandes de la communauté.
• GWT n’est pas à niveau côté Java. Oui, les génériques me manquent… on y prend vite goût.

Si vous voulez voir dans quelle direction va GWT, allez lire Making GWT Better.