Choix de framework Flex / GWT

Version imprimable

13/05/2011, 11h27
jadey

Choix de framework Flex / GWT

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.
18/05/2011, 13h56
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.
18/05/2011, 17h05
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. ;)
25/04/2012, 22h07
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 ;-)
16/05/2012, 09h53
valkeke

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

jadey écrit :

Citation:

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?:mouarf: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 :lol:: les bases, les fondations du web.

Eric Taix écrit :

Citation:

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 : 8O 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(:zoubi: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 :

Citation:

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 ..:calim2:...merci !
22/05/2012, 14h28
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:

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.
22/05/2012, 23h54
karbos
Citation:
Envoyé par 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:

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
Je ne trouve pas ça très juste ce que tu dis. Vaadin est l'ancienne librairie GWT ITMill... Elle utilise la techno GWT côté client, simplement elle fournit une panoplie de composants déjà optimisés et extensibles en Java. Mais rien n'empêche un bon développeur de faire aussi bien en partant des composants de base de GWT...
Pour en savoir plus sur ce qui est fait côté clientet côté serveur, l'extrait du livre de Sami Jaber publié sur developpez.com me semble assez complet et compréhensible (http://sami-jaber.developpez.com/tut...2/compilateur/).
Enfin, en pratique, on serait tenté de ne pas repartir de zéro. Quoi que GWT et les navigateurs évoluent très vite, est-ce que les librairies telles que Vaadin vont suivre la cadence ?
13/08/2012, 16h23
Eric Taix

Citation:

Envoyé par karbos

Je ne trouve pas ça très juste ce que tu dis. Vaadin est l'ancienne librairie GWT ITMill... Elle utilise la techno GWT côté client, simplement elle fournit une panoplie de composants déjà optimisés et extensibles en Java. Mais rien n'empêche un bon développeur de faire aussi bien en partant des composants de base de GWT...
Pour en savoir plus sur ce qui est fait côté clientet côté serveur, l'extrait du livre de Sami Jaber publié sur developpez.com me semble assez complet et compréhensible (http://sami-jaber.developpez.com/tut...2/compilateur/).
Enfin, en pratique, on serait tenté de ne pas repartir de zéro. Quoi que GWT et les navigateurs évoluent très vite, est-ce que les librairies telles que Vaadin vont suivre la cadence ?

Exact n'est pas très juste et tu as raison: coté client c'est bien du GWT qui est utilisé pour le rendu. Mais contrairement à du GWT lorsque l'on développe un panel qui contient 3 champs de saisie et 2 boutons, ce code n'est pas compilé en javascript et envoyé au navigateur (c'est ce phénomène qui fait que plus l'application est importante en nombre d'écran et de composants plus l'application sera lourde à charger en GWT).
Avec Vaadin le code qui permet de construire l'écran (le panel, les 3 champs et les 2 boutons) se situe coté serveur. Le serveur et le client communique ensuite via un protocole propriétaire (UIDL - User Interface Description Language). Ainsi lors du chargement du panel le serveur renvoie au navigateur la description de l'écran: les composants et leur placement. C'est du code Vaadin qui instancie les composants à ce moment là.

C'est en ce sens que je voulais dire que le code coté client avec Vaadin est toujours le même et ce quelque soit le nombre d'écran et de composants. Il dépend uniquement de la liste des composants utilisés au moins une fois dans le code (le widgetset).

Apres est ce que Vaadin va suivre la cadence ? Je ne sais pas. Pour l'instant cela a l'air bien parti. Et puis certains te diront "quelle cadence ?" Sans parler des rumeurs (certes estompées depuis sur la pérennité de GWT). Chaque framework a ses avantages et ses limites dans le cadre du projet dans lequel on l'utilise. Il faut donc d'abord cerner les contraintes de son projet pour faire un choix efficace et avec un gestion de risque maîtrisé.
13/08/2012, 17h40
NoClassDefFound

Justement, parlons contraintes, est-ce que tu t'orientes plus sur du client-centric (GWT) ou du server-centric(ZK).
Un des problèmes du client-centric est que tu exposes une partie de ta logique métier côté client ce qui peut être problématique.
Les frameworks server-centric peuvent quant à eux vite poser problème côté taille de la session http, mais bon c'est le prix à payer pour faire du "client lourd" avec un protocole stateless.
Selon moi les solutions basées sur Flex/JavaFX sont à oublier car sans avenir, d'ailleurs JavaFX est déjà quasiment enterré !
Vaadin je dis méfiance car cela peut poser problème en cas de bugs dans gwt, le temps que les correctifs soient intégrés dans Vaadin ...
A titre personnel, je préfères avoir un framework moins évolué, surtout côté IHM pure, mais sur lequel j'ai la main qu'un framework qui fait tout (sauf le café) mais qui en cas de bugs nécessite de mettre en place des procédures de controurment fastidieuses à implémenter et difficiles à maintenir.
La portabilité des applications web est une plaie, cela je supposes fait partie de tes contraintes principales.
18/08/2012, 22h53
marc.collin

la version 7 de vaadin permettra de faire du client et du serveur....