mardi 18 janvier 2011

Vaadin : la synthèse de deux mondes ?

Que l'on soit éditeur de logiciels, ou responsable applicatif au sein d'une DSI, on se retrouve souvent confrontés aux mêmes problématiques. L'une d'entre elles est de faire accepter ses logiciels par leurs utilisateurs. A ce stade, l'interface graphique, son ergonomie, sa réactivité - en bref, tout ce que l'on désigne aujourd'hui sous le terme d'expérience utilisateur - joue un rôle déterminant.

Pour développer des IHM, il y a deux stratégies : les clients lourds et les clients légers.
Les clients lourds, malgré l'étiquette de technologies dépassées qui leur collent maintenant à la peau, ont encore beaucoup de qualités : richesse des composants disponibles, fluidité d'exécution, robustesse, possibilité de créer des applications MDI. Du point de vue du processus de développement également, les clients lourds ont de nombreux avantages : même langage de développement que pour la partie métier, existence d'un IDE fourni par l'éditeur, possibilité de débugger le code de la couche présentation (!!!).

Du côté des clients légers, il y a probablement moins d'avantages, mais l'un d'entre eux, essentiel, a fait leur succès dans les entreprises : l'absence de déploiement préalable à l'utilisation sur les postes clients. Par extension, ce point permet également de simplifier la maintenance de l'application pendant toute la durée de son exploitation. Souffrant de trop nombreux handicaps les clients légers laissent peu à peu la place aux clients riches. Dans la longue liste de frameworks de RIA l'un d'eux semble avoir réussi la synthèse optimale du client lourd et du client riche : il s'agit du framework Vaadin de la société IT Mill.

Vaadin est une framework de développement d'applications Internet riches fournissant des composants graphiques et des contrôles accessibles au travers d'une API particulièrement bien conçue. Mais la singularité de Vaadin réside dans son architecture, orientée serveur, ainsi que son mode de développement qui se fait à partir d'un unique langage, Java. En fait, avec Vaadin, on ne pense plus serveur web/navigateur/requête HTTP, mais on pense comme lorsque l'on développe en client lourd : on crée des composants, on les rattache à des conteneurs, on leur lie des évènements, des sources de données, et c'est le framework qui se charge de générer le code HTML/JS/CSS nécessaire (il s'appuie pour cela sur GWT), ainsi que de gérer (de manière optimale, grâce à un UIDL propriétaire) les appels Ajax permettant les échanges de données entre le serveur et le client.

Avec mes collègues, nous avons utilisé Vaadin pour réaliser le prototype d'une application de traitement et de validation de factures, avec dans l'idée de remplacer à terme une application plus ancienne développée avec une framework maison basé sur des pages JSP et quelques soupçons de jQuery ça et là.


Après quelques mois d'utilisation, mes impressions sont les suivantes :
- Pour ceux qui ont déjà réalisé des applications en client lourd (que ce soit en Swing, en C# ou en Delphi), le temps d'adaptation à la philosophie du framework est quasi nul. Lorsque l'on se surprend à débugger son code métier et son code présentation en une seule passe, on oublie vraiment que l'on est en train de générer une application web !
- Vaadin s'exécute à l'identique sur Chrome, Firefox et Internet Explorer (8). Il propose un rendu des composants au look sobre, très professionnel, assez proche de Flex, même s'il est vrai que la bibliothèque de composants est moins fournie que celle d'Adobe,
- Vaadin est beaucoup plus facile à utiliser que GWT, car il n'impose pas de séparer les classes serveur et les classes client lors du développement. De plus, Vaadin n'est pas sujet aux lenteurs de compilation propres à GWT,
- La communauté est très active, les documentations sont de qualité et les corrections de bugs sont fréquentes. Nous avons rencontré un seul bug, il s'agissait d'une fuite mémoire. Sa correction a été publiée la semaine dernière.
- La bibliothèque d'add-ons est encore mince, mais elle s'enrichit de semaine en semaine,
- La plupart des composants de Vaadin supportent le drag'n drop.
- Vaadin possède des dizaines d'autres fonctionnalités toutes plus intéressantes les unes que les autres : support de nombreux serveurs d'applications, du portail Liferay, projets Maven, intégration avec Spring, intégration de widgets GWT...

L'image ci-dessous montre un widget GWT que nous avons développé pour visualiser des factures. Il permet de zoomer et faire pivoter les images, ainsi que de naviguer parmi les différentes pages d'une facture. Une fois développé (sans avoir eu recours au HTML5), le widget GWT est compilé et intégré à l'application comme s'il s'agissait de l'un de ses composants natifs.


Malgré une relative jeunesse, ce framework ne souffre pas d'un manque de maturité. La bibliothèque de composants graphiques gagnerait certes à s'étoffer encore ; la séparation entre la vue et le contrôleur pourrait être mieux encadrée (voire encouragée) par le framework, mais en ayant réussi la synthèse du client léger et du client lourd, Vaadin a tous les atouts pour devenir un framework de référence pour le développement d'applications d'entreprise dans les années à venir...

8 commentaires:

  1. xavier.benard@declasin.com14 mai 2012 à 23:12

    Bonsoir,
    Nous développons un app avec Vaadin, pour exactement les raisons que vous évoquez.
    Votre prototype à t il été au bout? (très intéréssé pour ma compta technique)... le widget est il disponible?

    merci
    Xavier

    RépondreSupprimer
    Réponses
    1. Non, malheureusement le widget est resté à l'état de prototype car nous ne sommes pas allés plus loin avec Vaadin/GWT.
      Il n'est donc pas disponible.

      Supprimer
  2. Bonjour, je suis très intéressé par votre application et notament comment vous avez fait pour afficher le PDF.

    Avez vous un conseil rapide à me donner ?

    Merci d'avance,

    Très cordialement

    RépondreSupprimer
    Réponses
    1. Bonjour Clément

      Il ne s'agit pas de documents PDF mais d'images au format PNG. Du coup, la problématique d'affichage ne se pose plus vraiment, car PNG est supporté nativement par le navigateur.

      Supprimer
  3. Bonjour,

    Pourquoi n'avez-vous pas continuer sur Vaadin ?

    Cordialement,

    RépondreSupprimer
  4. Bonjour et merci de votre intérêt pour cet article.

    Nous n'avons pas continué avec Vaadin car le projet de remplacement de l'ancienne application a été abandonné par la direction... et le prototype est resté à l'état de prototype.

    RépondreSupprimer
  5. Est-ce vraiment une bonne approche de partir sur Vaadin ? Dans mon entreprise, nous avons choisi AngularJS avec un serveur SpringMVC (car ce n'est pas une Single Page Application). Le choix a surtout été guidé par le besoin fort d'interaction utilisateur (diminuer la latence réseau).

    RépondreSupprimer
  6. Bonsoir,
    Partir sur Vaadin est un choix, ce framework est "server-centric" donc un bon réseau est nécessaire pour ce type d'application. De plus, il n'est pas forcément orienté multipages (sauf si vous codez une IHM façon Eclipse ou les navigateurs Web modernes : jouer avec les onglets) et encore il est "programmatique" par opposition à "déclaratif". Il est conçu pour développer des applications, pas des sites Webs (donc pas forcément des intranets). La maîtrise de ce qui se passe côté client est relativement faible (sauf à développer les Wigdets).
    Le choix de l'emploi d'une techno JS ouvre la voie à une maîtrise du côté client (Asynchronisme, autonomie, etc.). Ce n'est pas ce sur quoi Vaadin est fort aujourd'hui.
    Vaadin est puissant pour sa simplicité de programmation, et pour ma part, c'est sans équivoque. Je préfère de beaucoup coder en Vaadin qu'essayer de réaliser mon appli en JSF. Je maîtrise mieux mes coûts, c'est élégant et nous n'avons pas besoin de nous frapper différentes implémentations (certes, les objectifs diffèrent).
    Donc Vaadin, clairement oui, mais dans un contexte plus interne qu'extranet (réseau) et pour des applications pas des sites Webs (exit les ites de com).
    Cordialement,
    Sylvain

    RépondreSupprimer