Discussion :

[jadey]

Bonjour,

Je viens du monde JEE et je souhaiterais savoir si Flex / GWT peuvent répondre à certains de nos besoins:

On développe des applications intranet pour répondre à certains des besoins d'autres départements. Jusqu'ici avec du struts-layout combiné à du Javascript ça fonctionnait mais le rendu des d'IHM est assez vieillot, même s'il répond aux critères de rapidité d’exécution attendu par l'utilisateur d'un intranet.

En gros je saurai que ça nous correspond si sont remplis par ordre d'importance les critères de:

- Fiabilité (déjà utilisé dans des projets assez gros demandant la collaboration entre plusieurs intervenants avec peut être différents profils)

- Sécurité: Nos intranets peuvent très rapidement évoluer pour mettre à disposition de certains de nos partenaires quelques services par-ci par-là, au travers du net

- Robustesse (peu ou pas de bugs à l’exécution une techno assez mature et permettant d'ores et déjà de réaliser la majorité des fonctionnalités usuelles requises dans une IHM, j'entends composants déjà existants, grid avec tri et pagination, tree, tabs, fenêtre modale, fenêtre contextuelle)
Concernant ce point ci on est vite rassuré en regardant les différents showcase

- Techno d'avenir et pas un simple phénomène de mode.

- Rapidité.

J'ai vu que GWT avait beaucoup de concurrent, notamment Flex, JavaFX et Vaadin. Ce dernier me fait beaucoup de l'oeil et j'en lis beaucoup de bien, cependant un gros avantage pour moi à l'utilisation de GWT serait que tout soit Java dedans, ce qui est très important à mes yeux, mais peut être que ce que je perçois comme étant a priori quelque chose de bien, s'avère en fait à l'utilisation une faiblesse (codage d'IHM en Java...) j'espère avoir vos retours d'expérience.

Voila et merci d'avance pour toutes vos contributions.

[jadey]

J'ai eu plusieurs retours pour Flex par ailleurs.

Il ne s'agit pas de faire un débat Flex contre GWT (d'autres articles s'en sont chargés depuis longtemps), il s'agit juste de définir le meilleur choix dans notre cas à nous avec les contraintes que j'ai énoncées auparavant.

[womannosky]

J'ai un peu d'expérience en Flex et GWT alors voici mon opinion :
- Sécurité : GWT a l'air plus "secure" que Flex
- Fiabilité : GWT n'est peut être pas trop adapté aux gros projets
- Robustesse : convenable sur GWT, je ne sais pas trop en Flex
- Techno d'avenir : selon moi, GWT est beaucoup plus une techno d'avenir que Flex
- Rapidité : petit avantage pour GWT

Bon courage pour le choix de la techno.

[Eric Taix]

GWT est très bien mais à mon sens trop technique (pour pouvoir faire ce que l'on veut, optimisation, etc...).

Vaadin a raison de te faire de l'oeil ;-)

Vaadin en quelques mots:
+ framework full server side
+ développement 'style' Swing / SWT
+ orienté composant
+ basé sur GWT
+ les composants sont facilement modifiables via des thèmes (styles CSS) et ce n'est pas compliqué
+ Le temps de chargement est constant et ne dépend pas du nombre d'instances de composants que tu utilises dans ton application mais il dépend du nombre de composants différents que tu utilises (peu importe le nombre que tu vas afficher). Donc contrairement à GWT pour lequel les très grosses applications peuvent poser problème, avec Vaadin une grosse application se gère sans problème (coté serveur par contre il faudra prévoir plus de RAM en fonction du nombre d'utilisateurs simultanés)

Mais attention:
- orienté server side donc à la JSF : chaque evt est répercuté coté serveur qui en réponse génère l'UI via l'UIDL (User Interface Description Language). Donc verbeux entre le browser et le serveur, mais cela ne veut pas dire qu'il ne faut pas faire le choix de Vaadin.

Coût d'acquisition pour un développeur = 1 semaine.

A titre d'exemple voici le lien pour une application que j'ai développé en Vaadin et déployé sur CloudFoundry. Toute l'interface est du Vaadin (même les stats Google Analytics). CloudFoundry n'est pas des plus rapides mais l'application est relativement répondante surtout après le chargement. Tu remarqueras qu'en terme d'utilisation, le résultat est plutôt sympa. Le style utilisé (hérité de Runo) est plutôt type Web car c'est un site "grand public", mais Vaadin dispose de thème plus intranet.

http://dot-art.cloudfoundry.com/


Et mes fonctionnalités préférées pour la fin :
- interface dynamique. Cela signifie que tu peux créer des interfaces graphiques dynamiquement (ce qui est impossible avec GWT puisque l'UI est compilé en Javascript)
- compatible OSGI :-D

Bref je suis un adepte de Vaadin et je te conseille de prendre 2 jours pour faire une mini-application : tu seras forcément convaincu.

Ah et oubli Flex ;-)

[valkeke]

j'arrive un peu tard peut-être...

jadey écrit :

Il ne s'agit pas de faire un débat Flex contre GWT (d'autres articles s'en sont chargés depuis longtemps),

le problème : les articles que tu parles commencent à dater un peu aujourd'hui... il serait bon d'en refaire car GWT a bien évolué(version 2.4) depuis et Flex avec Adobe et les articles sur la mort de Flash(techno avec plugin sur navigateur..)voir Silverlight(Microsoft C#) qui est également un concurrent... la montée en puissance de HTML 5.
La différence de techno mais surtout de langage.

Si tu connais le java : tu pourras codé côté client(GWT) et côte serveur.
Si tu connais Flex(ActionScript) : tu pourras codé côté client et côté serveur?tu vas devoir apprendre un nouveau langage et bien appréhender la communication client/serveur.
Si tu connais le C#: tu pourras codé côté client(Silverlight) et côte serveur.
La question : est-ce l'avenir? les technos à base de plugin à installer sur la machine, sur le browser de ton client? GWT repose sur du HTML(donc HTML 5) et CSS et javascript : les bases, les fondations du web.

Eric Taix écrit :

GWT est très bien mais à mon sens trop technique (pour pouvoir faire ce que l'on veut, optimisation, etc...).

Avec GWT, on peut faire côté client ce que l'on veut : qu'est-ce qu'on peut pas faire que font les autres ?je serais curieux de savoir.....
Oui, GWT est un peu technique, normal car c'est un socle technique pour faire du web en full Java. Par exemple, la librairie graphique est un peu pauvre avec simplement GWT....c'est pour cela :
- soit on écrit ces propres composants(un jeu d'enfant !)
- soit on utilise GXT, ou smartGWT.
Sinon, y a Vaadin qui est une surcouche de GWT pour accélérer la réalisation d'application de gestion d'information. Je connais pas bien!la maturité de Vaadin?la communauté sur Vaadin?il prend en charge la persistence ou on peut choisir une techno?

ensuite Eric Taix écrit :

Le temps de chargement est constant et ne dépend pas du nombre d'instances de composants que tu utilises dans ton application mais il dépend du nombre de composants différents que tu utilises (peu importe le nombre que tu vas afficher). Donc contrairement à GWT pour lequel les très grosses applications peuvent poser problème, avec Vaadin une grosse application se gère sans problème (coté serveur par contre il faudra prévoir plus de RAM en fonction du nombre d'utilisateurs simultanés)

là je ne comprends pas, si tu peux expliciter ton idée .....merci !

[Eric Taix]

Ok je n'ai pas été clair et je vais essayer de l'être en peu plus ;-)


En GWT tout le code client s’exécute coté client (jusqu'à là cela semble normal). Donc plus le code coté client sera important (fonctionnalités, composants, etc...) plus la taille à exécuter coté browser sera important. Cela impacte le temps de chargement de l'application et donc sur les grosses applications, on splite en plusieurs modules afin de ne pas avoir à tout charger en un coup lors du chargement initial.

Sur Vaadin c'est différent. Il n'existe pas de code client ! Tout est server side (avec son inconvénient concernant les nombreuses échanges entre le browser et le server).

Ainsi un code client du type:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
  if (returnCode == 1) {
    Button btn = new Button("Hello world !");
    container.add(btn);
  }

=> Augmentera la taille à charger dans le navigateur avec GWT
=> Aura zéro impact avec Vaadin coté client

Avec Vaadin le "Terminal Adapter" retournera un le message UIDL indiquant qu'il faut créer un nouveau bouton et l'ajouter au container. C'est le "Client Side Engine" (situé dans le browser) qui interprétera le message UIDL et qui créera le bouton puis l'ajoutera dans le container.

Donc en conclusion:
- sur Vaadin la taille du code chargée coté client ne dépend pas du tout du code ! Mais seulement du nombre de composants GWT dans le WidgetSet
- sur GWT la taille du code chargée coté client dépend sur code client écrit


J'espère avoir été un peu plus clair.