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…

Ç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.