Discussion :

[palnap]

Bonjour,

Ayant participé à plusieurs projets de développement d'applis web, et actuellement me consacrant à deux projets, l'un en PHP+JS+ExtJS et l'autre en JEE5+GWT+GXT je me pose une question vraiment conne :

Pourquoi utiliser GWT? A part le protocole propriétaire RPC sacrément utile si le backend est en JEE, je ne lui reconnais aucune valeur ajoutée... Pourquoi donner tant d'importance à un "toolkit" qui n'apporte finalement rien de nouveau ? La google touch peut être?

"GWT's mission is to radically improve the web experience for users by enabling developpers to use existing Java tools to build no-compromise AJAX for any modern brother"

1) En quoi ça peut bien importer les utilisateurs de savoir si l'appli qu'ils utilisent est faite en Java ou en JS?
2) Les outils Java existants ça veut dire quoi? Eclipse? Ant? Utilisant NetBeans pour coder en PHP et JS aussi bien que pour coder en JEE et GWT, je ne vois toujours pas de différence... Si ce n'est la tâche Ant que j'ai du créer pour pouvoir utiliser le OOPHM dans NetBeans, les projets créés avec l'utilitaire GWT étant plutôt faits pour Eclipse :/
3) Ecrire des RIA "sans compromis" pour tous les principaux navigateurs, ya déja un bon pacson de libs JS qui existent et qui permettent de s'abstraire de la plateforme cible ( ExtJS )

De plus, on retrouve toujours les mêmes arguments qui ne tiennent pas la route pour peu qu'on déjà utilisé de manière effective JavaScript pour une appli RIA :
* l'appli peut être codée intégralement en Java propageant les objets métier jusqu'au client
=> il faut que toutes les classes utilisées dans le code client soit déclarées dans des packages GWT (donc il faut disposer des sources). c'est très difficile par exemple d'utiliser des entités JPA pleines d'annotations dans le côté client de GWT
* des meilleures perfs, de l'optimisation de partout caylafayte
=> je demande à voir des benchs, les optimisations c'est surtout une version différente de l'app par browser et par bundle de langue... je pense qu'à moins de coder avec les pieds un code JS sera toujours plus court que son homologue Java statiquement typé lui même traduit en code JS
* ya une partie de l'API du JDK qui est émulée dans GWT
=> des conteneurs statiquement typés, pour la plupart inutiles avec les structures dynamiques de JS
* le hosted mode qui permet de débugger en direk !
=> avec le super moteur de rendu d'IE sous windows (on peut débugger en direct en JS)
* le OOPHM, le deferred loading (runAsync()), et autres killerapps de GWT 2.0
=> on arriverait à la productivité de JS si l'OOPHM n'était pas aussi lent (à chaque appel RPC, le bouzin recompile les classes des objets échangés et fait freezer le navigateur qqs secondes - on le voit d'ailleurs dans une vidéo Youtube d'un gus qui veut montrer que GWT2 caydelaballe), le deferred loading on le fait en JS en 3 lignes depuis toujours...
* GWT ca minimise le code pour réduire le temps de téléchargement de l'appli
=> jamais entendu parler de YUI Compressor?

Donc en gros, tout ce qu'on peut faire avec GWT on peut le faire avec JS (ça parait d'ailleurs logique vu la manière dont gwt fonctionne ). Par contre avec GWT est-ce qu'on peut :
- Ajouter dynamiquement du code et modifier des structures de données pendant l'exécution de l'appli? (vachement pratique pour le debug)
- Mélanger les paradigmes dans l'écriture de son appli (impératif, OO, événementiel, fonctionnel) ?

Sans compter que les updates de GWT sont pas légions (ils annonçaient déja l'OOPHM l'hiver dernier), qu'on trouve beaucoup plus de ressources/de libs JavaScript sur la toile que pour GWT, et que les développements des dernières années de Google (GMail, Google Maps, ...) se sont toujours faits en JS (ah pardon j'oubliais Google Health !).

Bref le but n'est pas de faire un pamphlet anti GWT mais d'essayer de comprendre ce qui pousse les gens à aller vers cette techno qui objectivement n'apporte rien. L'effet de mode? La rigueur dans le dev qu'impose Java? Le RPC (contraignant, il faut que le backend soit en Java et c'est assez lent)? Tout simplement la peur du JavaScript?

[pedouille]

Bonjour,

Il y a beaucoup de choses dans ce que tu dis, et c'est d'ailleurs tout à fait justifié. En gros, ce que tu dis c'est :

Pourquoi utiliser GWT alors qu'on peut le faire en Javascript ?

En effet, c'est stupide ; pourquoi coder en C alors qu'on peut le faire en Assembleur...

Bon, mis à part ça, les avantages que je vois à GWT :
Quelques avantages de Java sur Javascript d'abord :
- Interfaces
- Classes abstraites
=> polymorphisme d'une manière générale
Qui ouvre la voie aux :
- Patterns de fabrique
- Adapteur, Façade, Décorateur, etc...
- Tout ce qui utilise le polymorphisme.

J'avoue que je ne comprend pas comment un développeur Java ne peut pas se sentir "libérer" de pouvoir utiliser ce genre de concept dans une appli. Clairement, en Javascript, à part quelques bricolages, on ne peut rien faire de polymorphique.

Ce qu'apporte GWT maintenant :
- Traitement correct des exceptions, qui permet de ne relever que certains types d'exceptions, et de laisser passer d'autres, de déclarer les comportements à risques, etc...
- Comme tu l'as dit, le RPC facile à mettre en oeuvre entre client et serveur Java
- Détection d'erreurs à la compilation, grâce au typage réellement fort (je peux déclarer un type Perimetre extends Float, qui sera un float, mais que je ne pourrai pas confondre avec un type Aire extends Float -> ça change la vie)
- Tout les outils existants pour Java :
Eclipse, génération de code (constructeurs, getters, setters, ...), debug, possibilité de packager des applications GWT dans des .jar et de les réutiliser de manière transparente dans d'autres applis GWT, et j'en passe ...


Enfin, dernier avantage, côté décideur :
- N'importe quel développeur Java peut rapidemment être un développeur GWT, alors que les bons développeurs javascript sont plus rares
- Les applis GWT sont de ce fait, plus facile à maintenir (moins de problèmes de turnover)
- Les applications sont moins dépendantes des développeurs qui les ont fait.

Bref, j'en viens à te retourner la question : comment peux-tu préférer Javascript à Java ?

[palnap]

Bonjour,

Il y a beaucoup de choses dans ce que tu dis, et c'est d'ailleurs tout à fait justifié. En gros, ce que tu dis c'est :

En effet, c'est stupide ; pourquoi coder en C alors qu'on peut le faire en Assembleur...

Non, ce que je dis c'est pourquoi coder en Assembleur alors qu'on peut coder en C ?

J'ai commencé sur un projet PHP+JS assez ambitieux (~24 000 lignes côté client, le double côté serveur) après avoir fais un peu de GWT. J'ai un peu poussé en direction du GWT préférant Java et son sacro saint typage fort. Mon collègue ayant eu de l'expérience avec JavaScript et avec la bibliothèque ExtJS (et qui peut pas piffrer Java) m'a assuré qu'il était beaucoup plus simple d'utiliser JS.

A priori réticent concernant JS, je dois dire que ce langage est fabuleux. Complètement dynamique (dans son typage, dans ses structures de données mais également dans son fonctionnement), donc très haut niveau et beaucoup plus souple que Java.

Bon, mis à part ça, les avantages que je vois à GWT :
Quelques avantages de Java sur Javascript d'abord :
- Interfaces
- Classes abstraites
=> polymorphisme d'une manière générale
Qui ouvre la voie aux :
- Patterns de fabrique
- Adapteur, Façade, Décorateur, etc...
- Tout ce qui utilise le polymorphisme.

J'avoue que je ne comprend pas comment un développeur Java ne peut pas se sentir "libérer" de pouvoir utiliser ce genre de concept dans une appli. Clairement, en Javascript, à part quelques bricolages, on ne peut rien faire de polymorphique.

Parlons en de Java, il est clair que dans un autre contexte, j'aime bien son modèle objet et son compilo ultra rigoureux qui nous évite des arrachages de cheveux à l'exécution. Par contre, là on parle d'ihm, de mise en forme, de traitements légers, l'essentiel du travail dans une appli web se faisant côté serveur. Du coup je vois pas l'intéret dans une couche présentation d'utiliser des design patterns... Justifie moi l'utilisation d'une Fabrique dans un de tes codes clients GWT et je suis prêt à revoir mon jugement (les seuls utiles très facilement reproductibles en JS sont la Facade, le Prototype et qqs uns comportementaux comme Observateur et Itérateur).

A moins que tu es un bon exemple d'une conception objet côté client, à quoi bon? Le typage dynamique de JS va te permettre d'écrire de construire tes ihm en beaucoup moins de ligne de code (compare le même widget complexe fait en ExtJS et en GXT, le code JS est plus clair et concis).

Ce qu'apporte GWT maintenant :
- Traitement correct des exceptions, qui permet de ne relever que certains types d'exceptions, et de laisser passer d'autres, de déclarer les comportements à risques, etc...
- Comme tu l'as dit, le RPC facile à mettre en oeuvre entre client et serveur Java
- Détection d'erreurs à la compilation, grâce au typage réellement fort (je peux déclarer un type Perimetre extends Float, qui sera un float, mais que je ne pourrai pas confondre avec un type Aire extends Float -> ça change la vie)
- Tout les outils existants pour Java :
Eclipse, génération de code (constructeurs, getters, setters, ...), debug, possibilité de packager des applications GWT dans des .jar et de les réutiliser de manière transparente dans d'autres applis GWT, et j'en passe ...

Traitement correct des exceptions? Les libs JS implémentant exploitant correctement le paradigme fonctionnel de JS (la plupart des bonnes libs JS) te proposent de définir des callbacks type onSuccess et onFailure qui te permettent de traiter les comportements non désirés.

RPC? Super pratique mais encore un peu lent comparé à un bête échange JSON (même si apparemment google planche sur des améliorations pour la v2.0)...

Détection d'erreurs à la compilation? Ben là c'est l'éternel combat typage statique vs typage dynamique, disons que chacun des deux possède ses avantages. Mais ici faut pas oublier que c'est un code statiquement typé qui va être convertit en code dynamiquement typé, donc au final...

Eclipse est tout à fait capable de pondre du code JS, de faire de l'autocomplétion (à la différence qu'il te proposera toutes les fonctions disponibles pour l'objet désiré, et ne fera évidement pas de distinction sur les types de retour) même si personnellement j'utilise NetBeans. Pas besoin de setters/getters en JS Pour le debug, je reste convaincu que le debug dynamique de JS (avec firebug, le truc immonde d'IE8 ou le Chrome Developper tool) est bien plus efficace que le debugger, bien Enfin, tu peux tout à fait packager du code JS (YUI compressor par exemple) et le linker dynamiquement avec une autre appli JS.

Enfin, dernier avantage, côté décideur :
- N'importe quel développeur Java peut rapidemment être un développeur GWT, alors que les bons développeurs javascript sont plus rares
- Les applis GWT sont de ce fait, plus facile à maintenir (moins de problèmes de turnover)
- Les applications sont moins dépendantes des développeurs qui les ont fait.

Si tu veux faire du dev web (que ce soit en GWT ou JS), tu dois déja connaitre les bases du web (HTML, CSS, avoir des bases de DOM, comprendre le fonctionnement des requêtes asynchrones), le reste (le langage en lui-même) c'est pas le plus important (et je suis convaincu que la prise en main d'un langage dynamiquement typé est plus aisé).
Concernant la maintenance, c'est vrai que Java impose une rigueur tandis que PHP ou JS t'obligent à t'en imposer une. Cependant, un code bien structuré et commenté JS sera toujours meilleur qu'un code Java pondu à l'arrache. Tout celà est à relativiser tout de même. L'avantage qu'à Java est qu'il est enseigné dans les IUT et Fac (avec des notions d'analyse et conception OO, les design patterns) tandis que JS est un langage qu'on commence à utiliser en partant de tutos ou d'exemples sur le net. Je te garantit que dans la "littérature" on trouve pas mal de bonnes pratiques à utiliser en JS.

Bref, j'en viens à te retourner la question : comment peux-tu préférer Javascript à Java ?

Faux mon bon monsieur , je préfère Java et le préfèrerai toujours dans la plupart de ses domaines d'applications (Fan de Java+NetBeans depuis plusieurs années, Java EE 6 et Glassfish 3 vont dépoter, qqs griefs contre JavaFX mais passons), seulement les moteurs de scripts de nos browsers permettent d'écrire du code dynamique. Pourquoi brider ce dynamisme en utilisant un langage statique (lui-même redynamisé plus tard par le traducteur GWT)?

Pro-du-cti-vi-té les gars!

[benwit]

Non, ce que je dis c'est pourquoi coder en Assembleur alors qu'on peut coder en C ?

On va dire que c'est de l'humour car cette analogie reviendrait à dire :
C = javascript
Java = assembleur

Il faudrait pas pousser mémé dans les orties

[palnap]

On va dire que c'est de l'humour car cette analogie reviendrait à dire :
C = javascript
Java = assembleur

Il faudrait pas pousser mémé dans les orties

C'était aussi de l'humour mais je voulais aussi souligner le fait que JavaScript en tant que langage dynamique était plus haut niveau que Java à bien des égards.

[pedouille]

Parlons en de Java, il est clair que dans un autre contexte, j'aime bien son modèle objet et son compilo ultra rigoureux qui nous évite des arrachages de cheveux à l'exécution. Par contre, là on parle d'ihm, de mise en forme, de traitements légers, l'essentiel du travail dans une appli web se faisant côté serveur. Du coup je vois pas l'intéret dans une couche présentation d'utiliser des design patterns... Justifie moi l'utilisation d'une Fabrique dans un de tes codes clients GWT et je suis prêt à revoir mon jugement (les seuls utiles très facilement reproductibles en JS sont la Facade, le Prototype et qqs uns comportementaux comme Observateur et Itérateur).

A moins que tu es un bon exemple d'une conception objet côté client, à quoi bon? Le typage dynamique de JS va te permettre d'écrire de construire tes ihm en beaucoup moins de ligne de code (compare le même widget complexe fait en ExtJS et en GXT, le code JS est plus clair et concis).

J'ai pas vraiment de projet présentable pour le moment qui font intervenir le client pour plus que de la présentation, mais ça vient ; un projet lié à la consommation énergétique dont les calculs de conso seront fait exclusivement côté client, (et dont le serveur ne servira qu'a stocker les infos persistantes et résultats de calculs).

Et un autre projet de "gestion documentaire" dont le client web est réellement riche (traitements côtés client, le serveur ne sert qu'a la persistance et à la synchro entre clients).

Dans ces applis, utilisation exclusive du MVC, le modèle étant implémenté uniquement côté client, et gérant sa persistance via les appel RPC sur le serveur ; pour schématiser, on pourrait considérer que le serveur est seulement un layer de base de données (très schématique quand même ).

Dès que je pourrais les présenter, je le ferai ; tu verras, les résultats sont assez bluffant, et la charge serveur quasi nulle...

Pour le reste, je crois que benwit a raison : c'est surtout une question de sensibilité ; si tu es à l'aise avec javascript, continu avec. Mais ce n'est pas parceque toi tu es plus productif avec Javascript que ça fait de javascript un langage plus productif que Java/GWT. Il faudrait faire des benchmarks avec deux équipes de dev équivalentes sur un projet identique pour pouvoir les comparer.

JavaScript en tant que langage dynamique était plus haut niveau que Java à bien des égards.

, le fameux comique de répétition.
J'ajouterai même que le robot mixeur, en tant que robot mixeur est plus haut niveau que Java à bien des égards.

[benwit]

Bonjour,
Ayant participé à plusieurs projets de développement d'applis web, et actuellement me consacrant à deux projets, l'un en PHP+JS+ExtJS et l'autre en JEE5+GWT+GXT je me pose une question vraiment conne :

Bonjour,
Comme dirait (la maman de ?) Forest Gump, il n'y a que la stupidité qui est stupide. Ta question n'a donc rien de conne du moment où tu t'interroges et cherches des réponses.

Pourquoi utiliser GWT? A part le protocole propriétaire RPC sacrément utile si le backend est en JEE, je ne lui reconnais aucune valeur ajoutée... Pourquoi donner tant d'importance à un "toolkit" qui n'apporte finalement rien de nouveau ? La google touch peut être?

Ah, la google touch ... ça doit jouer un peu quand même car je suis pas sûr que si la même chose avait été proposé par d'autres, ça aurait eu le même impact.
Ceci dit, ayant également travaillé avec Ext-JS seul et avec GWT, je vais essayé de répondre à tes questions. En te donnant mon point de vue qui est ma vérité mais pas LA vérité

1) En quoi ça peut bien importer les utilisateurs de savoir si l'appli qu'ils utilisent est faite en Java ou en JS?

Pour les utilisateurs, en rien. C'est pour les développeurs.

2) Les outils Java existants ça veut dire quoi? Eclipse? Ant? Utilisant NetBeans pour coder en PHP et JS aussi bien que pour coder en JEE et GWT, je ne vois toujours pas de différence... Si ce n'est la tâche Ant que j'ai du créer pour pouvoir utiliser le OOPHM dans NetBeans, les projets créés avec l'utilitaire GWT étant plutôt faits pour Eclipse :/

L'utilisation d'IDE (Eclipse, Netbeans, ...) pour coder du javascript tend à se développer. De même, il existe de bons débuggers JS (Firebug)
Ceci dit, au niveau IDE, les limites sont dues à la nature même de javascript. N'étant pas un langage statiquement typé, la suggestion de l'autocomplétion ne m'a jamais convaincu dans ce langage ... Et le refactoring, les tests unitaires, ça marche bien ? Je m'interroge ?
Au niveau du debugger, c'est un vrai plaisir de débugger avec eclipse, de passer du code client au code serveur en pas à pas ... Développer en javascript nécessitera d'utiliser un débugger adapté au navigateur si le problème est spécifique au navigateur et tous n'en disposent pas d'aussi bons que Firebug.

3) Écrire des RIA "sans compromis" pour tous les principaux navigateurs, ya déja un bon pacson de libs JS qui existent et qui permettent de s'abstraire de la plateforme cible ( ExtJS )

Il est vrai que de nombreuses librairies JS nous découplent du navigateur.
La venue de nouveaux navigateurs, nouvelles versions doit être gérée et on est donc dépendant de la réactivité du fournisseurs. L'effet Google joue pleinement ici car ils sont réactifs mais c'est probablement le cas d'autres (même de taille plus modeste)
L'intérêt pour moi d'avoir un découplage tel que GWT le propose (par deferred binding), c'est de ne fournir au client que le code qui lui est nécessaire (et éviter les hacks spécifiques immondes : if ie then, ... if gecko then ...)
Bon, il faut avouer que certaines librairies GWT n'ont pas encore compris cela ...
Un autre interêt potentiel, c'est que dans le futur, si une nouvelle techno émerge, on pourra imaginer un autre compilateur java->nouvelleTechno mais bon, ça reste spéculatif ...

De plus, on retrouve toujours les mêmes arguments qui ne tiennent pas la route pour peu qu'on déjà utilisé de manière effective JavaScript pour une appli RIA :
* l'appli peut être codée intégralement en Java propageant les objets métier jusqu'au client
=> il faut que toutes les classes utilisées dans le code client soit déclarées dans des packages GWT (donc il faut disposer des sources). c'est très difficile par exemple d'utiliser des entités JPA pleines d'annotations dans le côté client de GWT

Cette difficulté n'est pas à niée et il faut la prendre en considération dès le début ... Mais rien n'empèche de faire comme en JS : échange de XML ou de JSON.

* des meilleures perfs, de l'optimisation de partout caylafayte
=> je demande à voir des benchs, les optimisations c'est surtout une version différente de l'app par browser et par bundle de langue... je pense qu'à moins de coder avec les pieds un code JS sera toujours plus court que son homologue Java statiquement typé lui même traduit en code JS

Là, je pense que ça dépend du développeur. J'imagine qu'un très bon développeur Javascript pourra nous pondre un code aux petits oignons mais ils sont plutôt rares. Pour les autres développeurs, le temps gagné est plus à chercher du côté développement.
J'aime bien le côté offuscation du code (pour réduire la taille) qui ralentit ceux qui voudraient pomper notre code "effet de la mort qui tue"

* ya une partie de l'API du JDK qui est émulée dans GWT
=> des conteneurs statiquement typés, pour la plupart inutiles avec les structures dynamiques de JS
* le hosted mode qui permet de débugger en direk !
=> avec le super moteur de rendu d'IE sous windows (on peut débugger en direct en JS)
* le OOPHM, le deferred loading (runAsync()), et autres killerapps de GWT 2.0
=> on arriverait à la productivité de JS si l'OOPHM n'était pas aussi lent (à chaque appel RPC, le bouzin recompile les classes des objets échangés et fait freezer le navigateur qqs secondes - on le voit d'ailleurs dans une vidéo Youtube d'un gus qui veut montrer que GWT2 caydelaballe), le deferred loading on le fait en JS en 3 lignes depuis toujours...

La 2.0 n'est pas encore sortie officiellement, je ne me prononcerai pas sur ce point mais si c'est le cas, je comprend ta critique.

* GWT ca minimise le code pour réduire le temps de téléchargement de l'appli
=> jamais entendu parler de YUI Compressor?

Oui, c'est vrai.

Donc en gros, tout ce qu'on peut faire avec GWT on peut le faire avec JS (ça parait d'ailleurs logique vu la manière dont gwt fonctionne ).

Par contre avec GWT est-ce qu'on peut :
- Ajouter dynamiquement du code et modifier des structures de données pendant l'exécution de l'appli? (vachement pratique pour le debug)

OK pour le debug "à l'ancienne", moi je préfère le debug par eclipse (modifier mon code java et réactualiser).
Question de goût.

- Mélanger les paradigmes dans l'écriture de son appli (impératif, OO, événementiel, fonctionnel) ?

Pourquoi on ne pourrait pas ?

Sans compter que les updates de GWT sont pas légions (ils annonçaient déja l'OOPHM l'hiver dernier), qu'on trouve beaucoup plus de ressources/de libs JavaScript sur la toile que pour GWT, et que les développements des dernières années de Google (GMail, Google Maps, ...) se sont toujours faits en JS (ah pardon j'oubliais Google Health !).

Il est vrai qu'au début, ils ont un peu sur-vendus le truc car gmail n'a pas été écrit en GWT initialement. Mais GWT gagne en maturité ... Il y a de plus en plus de leurs projets qui l'utilisent ... Google Wave à venir qui a été très critique en interne et à conduit à de nombreuses améliorations de GWT.

Bref le but n'est pas de faire un pamphlet anti GWT mais d'essayer de comprendre ce qui pousse les gens à aller vers cette techno qui objectivement n'apporte rien. L'effet de mode? La rigueur dans le dev qu'impose Java? Le RPC (contraignant, il faut que le backend soit en Java et c'est assez lent)? Tout simplement la peur du JavaScript?

Je trouve que tu y vas un peu fort en disant que ça n'apporte rien.
Je peux concevoir que ça n'apporte peut être rien pour toi mais ce n'est pas le cas de tout le monde.
Tu as dit beaucoup de trucs justes, il existe des alternatives à GWT qui n'est qu'une approche possible.
J'ai commencé un projet en EXT-JS/JSP que j'ai fini par réécrire en GWT.
Pour quelques pages, pas de soucis. Les difficultés que j'ai rencontré, c'est lorsque le code grossi et l'application devient conséquente. Il faut bien penser au espace de nommage de ses variables JS sinon c'est des conflits en cascade. Il faut tester au fur et à mesure sur plusieurs navigateurs sinon on est pas à l'appris d'un truc con qui provoque un bug qu'on passe un temps fou à rechercher. Le refactoring en Javascript, je n'en parle même pas ... Le jour et la nuit avec Java.
Moi, je préfère les langages typés statiquement, le gain que GWT m'apporte dans MA productivité et c'est ma principal raison d'adoption.

Certains y arrivent en JS et c'est tout à leur honneur.
GWT n'est peut être pas fait pour eux tout simplement.

Des questions quand même :
Tes deux projets (NON GWT / GWT) sont ils comparables en taille ?
Quelle durée ont ils pris ? Quelle durée prendront les futurs projets (il faut s'habituer aux outils) ? Quid de la maintenance ?
Sont t'ils terminés ?
Il serait intéressant d'avoir des chiffres non biaisés (développeur à compétence égale, fonctionnalités des projets équivalentes, ...)

[plopinou]

Personnellement, je ne connais pas Javascript, je ne connais pas Ajax. Par contre, je connais bien Java, et mon serveur est en JEE. Dans mon cas, GWT est très pratique, je peux faire des contrôles formulaire côté client, je fais de la communication asynchrone très facilement, je fais tout ce que les développeurs Javascript/Ajax font, sans apprendre ces technologies.

Après, pour un développeur PHP qui connait bien Javascript, Ajax, et qui ne connaitrait pas Java, c'est clair que l'intérêt est plutôt limité !

[palnap]

L'utilisation d'IDE (Eclipse, Netbeans, ...) pour coder du javascript tend à se développer. De même, il existe de bons débuggers JS (Firebug)
Ceci dit, au niveau IDE, les limites sont dues à la nature même de javascript. N'étant pas un langage statiquement typé, la suggestion de l'autocomplétion ne m'a jamais convaincu dans ce langage ... Et le refactoring, les tests unitaires, ça marche bien ? Je m'interroge ?
Au niveau du debugger, c'est un vrai plaisir de débugger avec eclipse, de passer du code client au code serveur en pas à pas ... Développer en javascript nécessitera d'utiliser un débugger adapté au navigateur si le problème est spécifique au navigateur et tous n'en disposent pas d'aussi bons que Firebug.

Tout a fait juste, mais encore une fois, est-ce que tu fais beaucoup de refactoring et de tests unitaires sur tes IHM? Pour les problèmes spécifiques au navigateur, en utilisant ExtCore+ExtJS, j'en ai eu que 2 (un spécifique à IE résolu avec l'infame "outil de développement" d'IE8 et l'autre dû à un bug de la v1 de chrome)

Il est vrai que de nombreuses librairies JS nous découplent du navigateur.
La venue de nouveaux navigateurs, nouvelles versions doit être gérée et on est donc dépendant de la réactivité du fournisseurs. L'effet Google joue pleinement ici car ils sont réactifs mais c'est probablement le cas d'autres (même de taille plus modeste)

La version finale d'IE8 sorti en Mars 2009, support de ce navigateur au sein de GWT mi Juillet :/ A titre de comparaison, IE8 a été supporté par ExtJS dès Février

L'intérêt pour moi d'avoir un découplage tel que GWT le propose (par deferred binding), c'est de ne fournir au client que le code qui lui est nécessaire (et éviter les hacks spécifiques immondes : if ie then, ... if gecko then ...)
Bon, il faut avouer que certaines librairies GWT n'ont pas encore compris cela ...

Un bon point pour GWT, car pour faire ca en JS, il faudrait maintenir plusieurs codes, c'est pas le must. Par contre, je suis pas sûr que niveau gain de perfs ce soit mirobolant

Un autre interêt potentiel, c'est que dans le futur, si une nouvelle techno émerge, on pourra imaginer un autre compilateur java->nouvelleTechno mais bon, ça reste spéculatif ...

Vu le merdier que ca a été pour avoir un langage de script commun aux différents navigateurs, je suis pas sûr qu'ils vont recommencer l'expérience très vite

Là, je pense que ça dépend du développeur. J'imagine qu'un très bon développeur Javascript pourra nous pondre un code aux petits oignons mais ils sont plutôt rares. Pour les autres développeurs, le temps gagné est plus à chercher du côté développement.
J'aime bien le côté offuscation du code (pour réduire la taille) qui ralentit ceux qui voudraient pomper notre code "effet de la mort qui tue"

YUI Compressor !

La 2.0 n'est pas encore sortie officiellement, je ne me prononcerai pas sur ce point mais si c'est le cas, je comprend ta critique.

Wait & see, si les promesses sont tenues pour le RPC, ça peut dépoter (je le redis, pour moi c'est vraiment la valeur ajoutée de GWT niveau productivité), même si encore une fois, le loadAsync() est que le reflet objet du deferred binding de JS.

Pourquoi on ne pourrait pas ?

Parce que pas de fonctionnel dans Java (on peut toujours bidouiller avec les classes anonymes mais tu as pas la souplesse d'un vrai modèle fonctionnel avec closures) :/

Il est vrai qu'au début, ils ont un peu sur-vendus le truc car gmail n'a pas été écrit en GWT initialement. Mais GWT gagne en maturité ... Il y a de plus en plus de leurs projets qui l'utilisent ... Google Wave à venir qui a été très critique en interne et à conduit à de nombreuses améliorations de GWT.

Et quand est ce qu'on les verra ces améliorations ?

Je trouve que tu y vas un peu fort en disant que ça n'apporte rien.
Je peux concevoir que ça n'apporte peut être rien pour toi mais ce n'est pas le cas de tout le monde.
Tu as dit beaucoup de trucs justes, il existe des alternatives à GWT qui n'est qu'une approche possible.
J'ai commencé un projet en EXT-JS/JSP que j'ai fini par réécrire en GWT.
Pour quelques pages, pas de soucis. Les difficultés que j'ai rencontré, c'est lorsque le code grossi et l'application devient conséquente. Il faut bien penser au espace de nommage de ses variables JS sinon c'est des conflits en cascade. Il faut tester au fur et à mesure sur plusieurs navigateurs sinon on est pas à l'appris d'un truc con qui provoque un bug qu'on passe un temps fou à rechercher. Le refactoring en Javascript, je n'en parle même pas ... Le jour et la nuit avec Java.
Moi, je préfère les langages typés statiquement, le gain que GWT m'apporte dans MA productivité et c'est ma principal raison d'adoption.

Quand je disais GWT n'apporte rien je veux dire que tu ne peux rien faire en GWT que tu ne peux pas faire en JS (le fameux axiome de départ).
Arf, ExtJS + JSP, c'est un peu dommage car j'imagine que tu gérais la navigation dans une servlet? Dans mon app, c'est le client JS qui s'occupe de la navigation (en GWT aussi j'imagine que c'est très souvent le cas), je pense que ça cause moins de pb...
Donc tu penses comme moi qu'on peut réduire ce débat à "dynamiquement typé VS statiquement typé" ?

Certains y arrivent en JS et c'est tout à leur honneur.
GWT n'est peut être pas fait pour eux tout simplement.

Des questions quand même :
Tes deux projets (NON GWT / GWT) sont ils comparables en taille ?
Quelle durée ont ils pris ? Quelle durée prendront les futurs projets (il faut s'habituer aux outils) ? Quid de la maintenance ?
Sont t'ils terminés ?
Il serait intéressant d'avoir des chiffres non biaisés (développeur à compétence égale, fonctionnalités des projets équivalentes, ...)

[/QUOTE]
Deux projets relativement comparables en taille (même si à terme le projet JEE devrait prendre plus d'ampleur), a des niveaux d'avancements différents, amenés à évoluer perpétuellement (Scrum Powaa!), pas de métrique précise mais grosso merdo, une productivité similaire (avec l'OOPHM sinon ) mais plus de risques sur le projet GWT car limites imposées par GWT lui-même (GXT est de + plus jeune que ExtJS) et une marge de manoeuvre très réduite en ce qui concerne l'optimisation (et ça ça me fait peur quand je vois tout ce qui a pu être fait avoir une app aussi réactive dans le projet js, il va falloir compter sur Google pour la v2.0 ).

+