SmartGWT, un framework vraiment smart ?

Alors que GWT vient de souffler sa 5e bougie, ce framework signé Google aujourd'hui en version 2.3 et supportant HTML5 représente un socle très solide sur lequel il est possible de construire une bibliothèque complète de composants plus évolués encore, en vue d'être utilisée dans diverses applications.
En effet, alors que d'une part les composants simples (CheckBox, Radio Buttons, Lists, Suggest et autres inputs) qu'il nous offre couvrent majoritairement la plupart de nos besoins, il y en a pour lesquels Google a fait le choix raisonnable de nous fournir uniquement les fonctionnalités de base (Grid, FlexTable...). A nous développeurs s'offrent donc les possibilités soit d'étendre ces composants "trop basiques" afin d'en compléter les fonctionnalités, soit de se tourner vers un framework se basant sur GWT pour bénéficier rapidement de composants plus complets.
Cet article tente de présenter SmartGWT et s'il est possible (si oui, à quel prix) de l'utiliser dans une application professionnelle.
Tout d'abord, il faut savoir que SmartGWT est un wrapper de la librairie JavaScript SmartClient pour GWT.

Qu'est-ce que SmartClient ?

Concurrent sérieux d'ExtJS, SmartClient est un framework AJAX créé par Isomorphic Software en 2001, sous licence LGPL.
Il fournit entre autres un set de composants graphiques riches utilisant AJAX, offrant d'un point de vue fonctionnel de nombreuses possibilités telles que notamment :
- Une Grid permettant de créer des tableaux complexes gérant la pagination, le tri multiple, le groupage de données, le déplacement de colonnes, le choix d'afficher ou non certaines colonnes, le chargement des données par mapping XML...
- Des boutons évolués permettant d'appliquer des css évoluées (3 classes css par bouton pour définir la skin du début, du corps, et de la fin du bouton afin de pouvoir disposer de taille dynamique de boutons)
- Un TabPanel offrant la possibilité d'orienter les boutons à la verticale, etc.
...autant d'exemples qui apportent rapidement une richesse visuelle à l'application.
Cette liste n'a pas pour but d'être exhaustive, mais d'illustrer des exemples de besoins couverts par la librairie. Pour le détail des composants, le showcase est accessible ici.

La "version GWT" de SmartClient

Développé par Sanjiv Jivan (seul!), le portage de SmartClient pour GWT hérite donc de la totalité des composants de la librairie SmartClient, et en fait un acteur très sérieux dans le choix d'un framework graphique.
Les composants bénéficient d'une utilisation intuitive, tant côté développeur que côté utilisateur. Rapide et facile à mettre en oeuvre, l'objectif est atteint sans trop d'efforts. Le showcase est disponible ici, entièrement développé avec des composants SmartGWT.

Séduisant, non? Et pourtant...

Il est important de ne pas foncer tête baissée dans le choix de ce framework qui souffre terriblement d'incommodités multiples.
Comme nous l'avons vu, SmartGwt est un portage de la librairie JavaScript SmartClient pour GWT. Cela signifie qu'il s'adapte comme il peut, mais ne respecte pas la philosophie de GWT qui consiste à générer le code JavaScript entièrement à partir de Java. Ce framework se marie d’ailleurs très mal avec le nouveau UIBinder.
Pour l'avoir mis en oeuvre sur un projet "from scratch", j'ai été capable de faire des démonstrations de l'application au fur et à mesure du développement, mais me suis vite heurté à plusieurs problèmes :
Tout d'abord, la lourdeur du chargement initial. Sans optimisation, un simple "Hello World" fait en SmartGWT va peser pas moins de 3Mo à se charger chez le client. C'est un premier coup dur, et pas des moindres. Plusieurs techniques d'optimisation sont proposées par Sanjiv Jivan, notamment la compression de l'application sur le serveur pour optimiser le temps de transfert, couplée à une décompression côté client. Mieux vaut donc compter sur une bonne configuration chez le client, pour un gain d'environ 1Mo.
Ensuite, bien que le showcase ne le révèle pas du tout, j'ai été heurté à la lenteur d'exécution. En effet, avec des données bouchonnées ou peu nombreuses, on obtient des temps d'exécution (d'affichage des données dans un tableau par exemple) tout à fait corrects. Dès qu'on dépasse le seuil du millier d'objets, quelques secondes d'attente vont être nécessaires, avec dans la plupart des cas un gel du navigateur, ce qui peut être très mal venu quand c'est répété.
Inutile de dire que lorsqu'on créé des composants évolués à la volée pour chaque itération d'objet, le navigateur va afficher régulièrement le message "un script sur cette page est peut-être occupé ou ne répond plus, Vous pouvez arrêter le script maintenant ou attendre pour voir si le script se terminera." Il faut savoir que sur nos machines de développeurs, ce message apparaît très nettement moins que sur un poste moins performant.
D'autre part, s'il est facile de customiser un composant fourni par le framework, la librairie JavaScript reste encapsulée et il devient difficile d'étendre des classes pour répondre à des besoins particuliers... D'autant que la migration entre des versions du framework n'est pas sans coût et doit impérativement être estimée dans le projet.
Enfin, la communauté d'utilisateurs de SmartGWT restant faible, le support en est aussi relativement actif, assuré par 2 personnes tout au plus, dont Sanjiv Jivan.

Conclusion

Il est donc essentiel de bien mesurer les impacts du choix d'un tel framework, et d'identifier clairement quelles sont les raisons qui nous poussent à le choisir. Est-ce pour bénéficier du look and feel sexy et des possibilités de customisation des composants? A-t-on un réel besoin des fonctionnalités avancées proposées par SmartGWT? Les postes clients sont-ils suffisamment équipés (matériel et réseaux) pour supporter la charge?
Le fait de devoir développer des fonctionnalités manquantes peut apparaître superflu au premier abord, étant donné qu'on peut les trouver dans SmartGWT, mais cela peut souvent se révéler bien moins couteux que le redéveloppement de l'application après abandon du framework.
N'hésitez donc pas à faire des POC avec des vraies données surchargées volontairement, bouchonnez le moins possible, et simulez tant que possible les cas réels d'utilisation de votre application, sur un poste client directement.

2 commentaires

  1. Merci Philippe pour cette présentation du framework SmartGWT, ton passage sur les performances montre encore une fois les faiblesses rencontrées avec GWT au début, avec le temps il y aura de grands progrets.
    As-tu utilisé ce framework dans un contexte client ou bien à titre personnel ?
    Encore merci.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Captcha *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.