| french | english |
 |
|
| Créer un compte | |
| 13-10-11 / 22:52 : Vaadin : encore loin de Cappuccino (cjed) |
| Le framework Vaadin, en développement depuis au moins un an (et sorti bien après Cappuccino) propose une gestion applicative côté serveur (Java), en limitant les messages json à la modification de l'état des contrôles (GWT). De plus, le code de communication étant générique, la phase de génération Java vers Javascript n'est plus requise contrairement à Ext GWT ou Smart GWT. Cependant cette solution n'est toujours pas au niveau de Cappuccino dans la pratique, au niveau du résultat obtenu, des performances et des concepts : - L'intérêt de Java côté serveur pour la logique de navigation est réduit (il s'agit uniquement de contrôler l'interface et les actions, pour lesquelles Javascript est suffisant), Java étant plus utile pour la couche services (plus grande complexité, et notamment accès à des systèmes hétérogènes via des connecteurs). - La définition de l'interface et des actions reprend la syntaxe et les principes de Swing, très limité dans le nombre de design patterns mis en oeuvre, et très loin de la véritable approche par délégation de l'AppKit (responsability chain, binding dynamique, KVC, KVO, delegates au lieu d'héritage). Il n'y a pas d'architecture, ni élégante ni innovante. Les fonctionnalités se limitent aux widgets, contrairement à l'AppKit qui fournit des solutions et best practices (éprouvés) pour les différents besoins d'une application. - Une telle solution pour de la génération de code client Cappuccino serait très longue à mettre en place et difficile à maintenir, obligeant à définir des objets Java wrappers/generateurs pour chaque widget de l'AppKit (de plus celui-ci contient de nombreux objets qui ne sont pas des widgets). Cette redondance inutile ne serait pas intéressante (la notion de proxy côté client - via CP2JavaWS - pour l'appel de services semble suffisante). - Objective-J 2.0 apportera un parseur moderne, et WebKit permet déjà un debuggage aisé. La validation par une compilation Java semble donc d'un intérêt limité, en plus de rajouter de la lourdeur. De plus dans tous les cas les bugs liés aux changements d'états ou à l'affichage des widgets nécessitent de comprendre le code Javascript généré par GWT (même si la plus grande partie de la couche navigation est à présent côté serveur en Java - contrairement à Ext GWT et Smart GWT). - Certains contrôles (notamment les Table view) sont très limités dans Vaadin. Mais surtout les performances sont très faibles : pendant le scrolling live, les données mettent plusieurs secondes à se réafficher. Le contournement choisi est de présenter un message d'attente (avec les lignes en cours de chargement, qui n'est donc jamais à jour/exact au fur et à mesure que l'on scrolle). Cappuccino et CP2JavaWS permettent de naviguer parmi plusieurs milliers d'éléments sans pause (sur WebKit), ou avec des ralentissements très ponctuels (Firefox). Le mécanisme de Vaadin requiert de plus nombreux appels du fait que la logique applicative est principalement côté serveur (le client web n'est pas autonome, pas de cache dans les table view, etc.), et limite donc les performances. - Vaadin ne propose pas d'abstraction de la couche media contrairement aux implémentations de Quartz/CoreAnimation et le DocumentBridge de Cappuccino. - les layouts proposés ne sont pas aussi évolués que le layout par contrainte (et récursif/automatique) de Cappuccino. - l'Interface Builder de Vaadin, inspiré d'Atlas/IB dans le design, possède les mêmes limitations que les autres éditeurs (ne reprend pas les principes qui font l'intérêt d'IB). - le thème par défaut, très inspirée d'Aristo, n'est pas aussi abouti. Il suffit de comparer l'application Vaadin Tunes avec ThatMusicApp. Le rachat de Sofa (créateur du thème Aristo) par Facebook récemment démontre leur avance. Tout comme Google a toujours utilisé un design minimaliste par manque de compétence dans ce domaine. |
| Commentaires |
| Poster un commentaire |