Devrais-je utiliser Vaadin Framework [fermé]

Après presque 1,5 année de développement d'une application GWT pas si énorme, en utilisant toutes les meilleures pratiques que j'ai apprises des dernières E/S Google comme MVP, EventBus, CommandPattern, etc. Je dis cela du fond de mon cœur: après avoir passé des jours à essayer de faire fonctionner les choses comme mon équipe et mon client voulaient à la fois techniquement et visuellement, même après la sortie de UiBinder, Vaadin est venu à moi comme une lumière au bout du tunnel.

Après avoir écrit près d'un millier d'actions standard pour modèle de commande, mille autres présentateurs et vues et mille autres gestionnaires d'événements, etc.. Ne pas avoir à traiter près de 75% de ces classes et maintenir toujours une bonne approche de modèle (appfoundation add-on), un peu de surcharge réseau est acceptable. Avec Vaadin, prêt à l'emploi, vous obtenez de bons widgets, pagination, liaison de données, layouting impeccable. Tout cela pour quoi? Un peu plus de consommation de mémoire côté serveur.

Je pense que je peux dire que c'est acceptable parce que je ne construis pas le prochain Facebook ou quelque chose. Je peux toujours gérer des milliers d'utilisateurs simultanés par serveur moyen tout en maintenant des allers-retours à faible latence.

Avec Vaadin, je peux construire une belle application avec près de la moitié des lignes de code et encore l'application semble plus complète. :-)

!! Mise à jour 23 février 2011: Je ne peux pas insister sur la façon dont on devrait être conscient des limites de chaque cadre. Vaadin n'est pas différent. Il faut être conscient que Vaadin abstrait toute forme de HTML ou JavaScript. En outre, le HTML résultant est très lourd et vous devriez prendre soin des changements d'état de l'histoire vous-même. Alors, soyez conscient de ces frais généraux lorsque vous construisez votre projet.

Disclaimer : Je ne suis affilié à aucune des bibliothèques mentionnées ci-après, mais je connais assez bien mon chemin.

Comme vous, je suis tombé sur ce post en réfléchissant à la pile / cadre à utiliser pour un nouveau projet. J'ai eu une solide expérience avec le jeu! (ok, dans Scala, mais ce n'est pas pertinent ici) mais les widgets convaincants et leur intégration transparente avec le côté serveur + le Swing comme le développement ont piqué mon intérêt. C'était à la fin de 2010, et comme les réponses m'a convaincu de faire Vaadin un essai, j'ai décidé de revenir et écrire la réponse que j'aurais aimé lire ici, esp. comme la question est toujours pertinente aujourd'hui. Pendant ce temps, Vaadin est passé de la version 6 à 7 avec quelques améliorations notables qui étaient nécessaires, jouer! je suis passé de la version 1 à 2 et j'ai (+une petite équipe) terminé un petit nombre de projets réussis avec les deux cadres.

Je pense que la comparaison est intéressante car les deux frameworks

1. exécuter sur le JVM et peut tirer parti de son écosystème abondant
2. ne pouvait pas être plus en désaccord dans leur approche des applications web et ce que vous, en tant que développeur devrait se soucier, et
3. dans une moindre mesure, comment ils se rapportent à Java EE.

Louange

En une phrase, si vous trouvez convaincante l'idée de porter une application de bureau sur un navigateur tout en étant complètement abstraite du mécanisme HTTP request/response sous-jacent, alors Vaadin est probablement votre candidat pour faire une application web. Son approche Swing like À la programmation peut être un jeu d'enfant pour ceux qui sont les plus heureux loin du bas niveau de HTML et JavaScript. Une nouvelle requête à votre application démarre en effet une nouvelle instance et le reste du flux dépend de vous et de votre logique. Les liens reviennent aux bons vieux boutons pour la navigation et vous êtes libre de composer vos mises en page en utilisant les nombreux modèles intégrés sans jamais être nécessaire de modifier le HTML ou le CSS. L'API est généralement assez cohérente et certes bien documenté (le Livre de Vaadin est une lecture obligatoire. Faites-le à fond autant de choses sont facilement disponibles, par exemple. lier vos beans aux composants et validateurs, ...). Les widgets ont une bonne compatibilité globale entre les navigateurs, assurant ainsi un comportement cohérent de votre application sur un large éventail de clients.

Vérification de la Réalité

Nous avons passé un bon moment à développer et à tester nos applications Vaadin. Les choses sont devenues plus claires et plus nuancées lorsque nous publié la première version et a commencé à recueillir des commentaires. Nous avons réalisé que nous avions été biaisés de manière assez fondamentale , à savoir:

1. Dans 201x, la plupart des utilisateurs ont une longue histoire d'utilisation du web, et peu d'entre eux utilisent à peine des applications de bureau plus. Le point clé ici est que les navigateurs ont standardisé l'interaction UX avec des liens hypertextes, un bouton back, un bouton forward et un bouton reload, des onglets omniprésents et parfois des fenêtres, et l'idée de base que la plupart des actions déclenchent une requête HTTP et attendent une réponse . C'est le contrat implicite que les sites Web respectent et autour duquel ils sont construits. Par conséquent, nous n'aurions pas dû être surpris lorsque les utilisateurs se sont plaints qu'ils ne pouvaient pas utiliser les boutons Précédent/Suivant Comme ils étaient habitués, ou que les onglets ne fonctionnaient pas de la manière attendue. Et nous sommes convenus. Nous avons brisé le contrat invisible liant les utilisateurs et les navigateurs. En fait, nous étions nous-mêmes implicitement ne pas utiliser notre navigateur avec le Vaadin app la façon dont nous l'avons utilisé avec tout autre site web. Bien sûr, vous pouvez revenir au livre susmentionné et lire attentivement sur la réplication d'une expérience de navigation web avec des fragments D'URL et vous verrez qu'il est en fait plus impliqué que prévu parce que les applications Vaadin sont avec état. De plus, les paradigmes MVC ou MVP ne sont que vaguement imposés au développeur, contrairement au jeu! où il n'y a pratiquement pas d'autre option. Ne prenez pas cela à la légère mais votre cerveau est habitué au brillant écran blanc affiché pendant une fraction de seconde après un changement de page. Lorsque les utilisateurs cliquent et s'attendent à être pris une nouvelle page, le navigateur reconnaît en montrant le sablier (ou ses variantes). Avec AJAX, les demandes sont placées dans les coulisses. Il y a aujourd'hui des endroits où les petites frappes AJAX presque chirurgicales sont devenues la norme, mais pas encore pour les mises à jour majeures de l'interface utilisateur.

2. Les applications avec État apportent leur part de défis... et les ennuis. Équilibrage de charge (si vous êtes concerné) pour un c'est plus compliqué. Le concept de transaction est totalement différent car les sessions Vaadin couvrent de nombreuses demandes et sont donc longues contrairement à L'approche basée sur le repos, mais relativement courte durée en termes D'UX. En effet, il n'est pas rare pour les utilisateurs de revenir à une forme qu'ils ont commencé heures pour terminer leur tâche. Cela pourrait, en théorie, fonctionner avec Vaadin aussi, mais vous devrez garder les sessions vivantes pendant longtemps, longtemps avec la mémoire bloquée tout le temps et bien réfléchir cela évoluerait avec les utilisateurs simultanés.

   Les pages avec État sont également plus difficiles à partager pour les utilisateurs, sans parler des signets (en supposant que vous avez traité des fragments D'URL).

3. Enfin, nous partageons l'impression que l'INTERFACE utilisateur est généralement plus lent que la logique étant sur le serveur. Bien sûr, vous pouvez toujours créer un widget chargé de JavaScript côté client pour réduire le nombre d'allers-retours, mais vous devrez inévitablement faire des mises à jour de L'interface utilisateur sur le serveur. Le JS est déjà assez lourd à interpréter dans mon expérience et fait une expérience moindre sur les appareils mobiles (Je suis conscient de TouchKit, mais quand même: les applications HTML5 sur les appareils mobiles ne le coupent pas pour moi). Gardez également à l'esprit que le thread de L'interface utilisateur est actif après la publication d'une requête (c'est-à-dire. action de l'utilisateur côté client, similaire à tirer les mises à jour de L'interface utilisateur) et vous sera accessible via différents écouteurs. Cependant, la mise à jour de l'interface utilisateur à partir des threads d'arrière-plan est plus compliquée (par exemple. pousser les mises à jour). Vaadin 7 amélioration de la situation à cet égard cependant, en particulier avec relativement html plus léger généré. Des améliorations significatives de la réactivité de L'interface utilisateur ont été perceptibles en activant simplement la compression HTTP.

Conclusion

Nous avons donc fait une pause et nous nous sommes demandé ce que nous trouvions si attrayant dans L'approche Vaadin pour commencer. Le développement initial avait été un tour relativement lisse donnant des résultats rapides mais retravaillant certains concepts pour répondre aux attentes Web UX nous a donné une forte impression de nager à contre-courant. Nous avons conclu que l'idée séduisante d'être abstrait (obscurci?) du mécanisme de requête/réponse HTTP s'est avéré une épée à double tranchant qui a dévoilé l'incompatibilité d'impédance réelle entre les applications web et les applications de bureau.

Au lieu de prétendre que le web est encore une autre couche, nous avons fortement estimé qu'il fallait adopter la façon dont il fonctionne et cela commence par avoir une application centrée sur L'URL (comme imposé par Rails/Django/Play). Vous avez probablement entendu quelqu'un dire que les données survivent à l'application. De nos jours, les données sont référencées par les ressources URL, donc on pourrait dire que les URL survivent aux données. Après tout, ils sont ce que les gens signet, ne sont-ils pas? La séparation fondamentale des préoccupations devrait donc également s'appliquer à ce niveau. C'est probablement pourquoi le web est devenu si populaire en premier lieu. Nous avons donc revisité notre application pour la structurer davantage autour d'un contrôleur central répondant aux actionsà la Play faites sur une ressource distincte chemin.

Pour l'instant, nous maintenons nos applications Vaadin, mais en raison de certaines de ces contraintes et du changement de paradigme fondamental, nous ne commencerons pas de nouveaux projets avec elle. Cependant chapeau à l'équipe qui a construit un framework Web Java 360° techniquement cohérent, cohérent et bien documenté nécessitant très peu de connaissances sur le fonctionnement interne du web. À la hausse, ils soutiennent même leur cadre avec une entreprise vendant des services de conseil. Je suis reconnaissant pour l'expérience et pour la façon dont il m'a fait réévaluer mes points de vue sur les applications web. Je vais suivre de près son évolution, mais nous avons certainement besoin de plus de contrôle et de granularité.

Espérons qu'un jour Vaadin se libérera de toute L'architecture de Servlet sur laquelle il s'appuie pour avoir son propre serveur HTTP. Mieux encore serait une conception MVC plus profondément enracinée dans le cadre. Mais c'est un peu improbable dans un avenir prévisible car il semble avoir trouvé une niche lucrative parmi les gorilles Java d'entreprise chevronnés qui ne jurent que par EE. Briller sur.

TL; DR : je pense que Vaadin manque le point de ce que sont les webapps et, plus important encore, comment ils devraient se comporter. Il est temps que les programmeurs adoptent le web et la façon dont les utilisateurs interagissent avec lui (ie. bouton Retour, bouton Recharger, onglets et signets). Plus une application web est proche des requêtes HTTP et de la sémantique (verbes), plus elle est susceptible de correspondre aux attentes des utilisateurs. Et c'est la clé.

EDIT : Si vous avez une expérience Python, je vous recommande fortement essayer Flask aussi pour obtenir une saveur de programmation d'applications web centrée sur l'url et basée sur REST.

EDIT 2 : Si pour une raison quelconque vous pensez que vous devez utiliser un framework de type Vaadin à pile complète, essayez Meteor. C'est un framework basé sur JavaScript (à la fois frond et back end) qui s'exécute sur Node.js avec une communication asynchrone se produisant via WebSocket (donc une latence plus petite que la requête / réponse) et il est réactif par défaut. Un certain nombre de choses que je n'aime pas à Vaadin ont été adressé dans Meteor. Par exemple, la logique des mises à jour de L'interface utilisateur s'exécute sur le client, ce qui le rend beaucoup plus réactif que dans Vaadin. Les gens dans les communautés JavaScript et Java ne se croisent pas beaucoup, mais quand j'en ai entendu parler, le parallèle avec Vaadin m'a frappé immédiatement. Il bénéficie actuellement d'un certain élan dans la communauté pour des raisons similaires à celles qui ont rendu Vaadin populaire, à savoir. la possibilité de créer des applications Web de type bureau. Essayez-le si vous avez également réalisé que Java n'appartient pas beaucoup à l'image des futures applications web ou si vous êtes fatigué de ces longs cycles de déploiement lorsque vous appuyez sur Actualiser est tout ce qu'il devrait prendre. Mais réfléchissez à deux fois avant de lier une application entière à une seule bibliothèque.

Le discours habituel sur Vaadin concerne le jeu de widgets et s'inquiète de la communication aller-retour entre le client et le serveur.

Mais à mon avis, cela néglige l'aspect le plus important (peut-être révolutionnaire) de Vaadin: il élimine complètement la tâche de concevoir et d'implémenter la communication client-serveur habituellement requise pour les applications AJAX (le "A" et "X" en AJAX).

Avec Vaadin, vous pouvez complètement oublier les DTO (objets de transfert de données), problèmes de sécurité basés sur le protocole, hiberner les exceptions de chargement paresseux, etc.

Dans un certain sens, vous écrivez simplement une ancienne application de bureau Java Swing, seulement vous utilisez une boîte à outils D'interface utilisateur différente de Swing.

D'après mon expérience, GWT nécessite beaucoup de code standard et lent lors de la construction d'une interface utilisateur compliquée et riche. Habituellement, nous traitons de modèles d'application assez complexes qui contiennent de nombreux objets de domaine persistants. Pour apporter toutes ces données au client, vous devrez introduire un modèle client séparé et fournir un mécanisme de conversion de données. Nous avons utilisé Dozer à cette fin et il faut beaucoup de temps pour mapper chaque fichier, créer des convertisseurs personnalisés et tester tout cela.

D'autre part si ne tombent pas dans la suringénierie et si l'application n'est pas très compliquée, vous pouvez profiter de l'utilisation des ressources client et avoir moins de charge sur le serveur. De cette façon, vous pouvez réduire considérablement la communication avec le serveur et obtenir un logiciel beaucoup plus réactif.

Vadin semble très développeur frinedly:) mais j'ai un peu peur de "massive AJAX attack" sur le serveur. J'ai de L'expérience dans ZK et souvent nous avons fait face aux problèmes de performance lorsqu'une opération triviale sur L'interface utilisateur fonctionne lentement car elle nécessite une communication avec le serveur.

Wicket est un autre bon cadre, mais il est plus approprié pour les sites Web. Il peut fonctionner avec et sans AJAX, peut être indexé par les moteurs de recherche. Et la chose la plus attrayante, il traite du code HTML propre - pas de balises personnalisées, pas de structures de contrôle, une séparation stricte des préoccupations et seulement namigs wicketid spécifiques pour les composants.

Cela dépend principalement de vos besoins:

1. Si vous avez besoin d'une application super rapide et simple-utilisez GWT et utilisez ressources clients
2. Si votre application est assez complexe que Vaadin semble être la meilleure option
3. Si votre application est publique et que vous avez besoin d'une capacité à l'indexer pour le référencement, choisissez Wicket.

La chose est, pour un développement sérieux, vous ne pouvez pas oublier quoi que ce soit, encore moins les DTO.. je suis en train d'amerrir la couture, et le concept d'interface utilisateur côté serveur juste parce que je souhaite un contrôle plus fin sur ce qui se passe sur le fil.. le problème de vaadin pour moi est précisément cela, ayant l'état du côté serveur..

Il y avait des "préoccupations" concernant L'utilisation de sessions Wicket pour gérer les états des composants et l'évolutivité similaire aux arguments sur Vaadin et le traitement côté serveur. J'ai appris au cours des 10 dernières années que la communauté Java a généralement tort sur la façon de mesurer le potentiel d'un framework web (entre autres choses). De JSF à Grails, il faut généralement quelques centaines de Go de mémoire et au moins une douzaine de fichiers JAR open source avec des fonctionnalités qui se chevauchent et inefficaces pour obtenir une production l'application en cours d'exécution. Regardez autour de vous et vous verrez que la plupart des sociétés d'hébergement web n'offrent pas une option java pratique en raison du chemin erratique que les technologies java ont pris pour les frameworks web. GWT 2.1 est toujours une douleur à utiliser en raison de la vitesse de compilation et il devient juste sérieux avec MVP et les tables de données qui auraient dû être là depuis le début. J'aime Wicket mais Vaadin semble prometteur... mais sachant comment vont les frameworks Java, je suis sûr qu'ils vont se tirer dans le pied à un moment donné mais je doute que ce soit à cause d'un traitement lourd côté serveur.

Pour construire une bonne interface utilisateur, je dirais que ce serait la voie à suivre. En Plus, c'est très bien documenté.

Je l'utilise depuis quelques semaines et je vraiment l'aime jusqu'à présent. Le Code est solide, docs une nouvelle bonne, construction très logique, les résultats finaux sont excellents.

Je l'aime en combinaison avec Hibernate pour trier toute l'ennui de la base de données.

Plus facile à déployer (avec Tomcat, vous pouvez simplement télécharger un seul .Fichier de guerre via l'interface web, ne pouvait pas être plus facile)

Jetez un oeil à la démo Vaadin construire avec Maven: http://asolntsev.blogspot.com/2009/11/vaadin-demo.html

Il est également intéressant de considérer Apache Wicket {[2] } comme une alternative forte pour les frameworks Java Web UI orientés composants. Vaadin sonne bien et je ne veux pas nuire à cette discussion, mais le choix est une bonne chose. Il y a quelques exemples avec la source liée à la page d'accueil, et encore plus sur le site WicketStuff, et l'excellent Livre de Manning forme une excellente documentation tierce.

Je pensais que Wicket était la voie à suivre, jusqu'à ce que j'ai essayé de le faire fonctionner efficacement et a commencé une dépression (blague). Ensuite, je suis passé à GWT, ce qui avait l'air génial, mais il y a tellement de code de Plaque de chaudière à écrire et la documentation n'est pas si géniale... - >La lumière est venue de Vaadin: simple, opérationnel, pas de bugs jusqu'à présent... !!!

Dans notre entreprise qui est principalement une grande maison Java SW (entre autres choses), il est venu sur nous une chance de créer un nouveau web basé product.It était un ensemble de produits et il y avait beaucoup d'équipes dans trois pays qui développent ce. En ce qui concerne notre équipe, j'ai eu le choix D'utiliser Vaadin pour tirer parti de notre expérience de développement java.J'ai cherché Google pour m'aider dans ma décision. J'ai aussi lu ce post; cependant, j'ai choisi de ne pas utiliser Vaadin bien que beaucoup d'autres équipes aient choisi Vadin. Voici les raisons d'un mail que j'envoie à ce moment-là avant de commencer sur le produit (à Vaadin ou non). C'est de mon point de vue personnel et la méfiance des cadres en général est toujours en moi à des degrés divers. Donc, je voulais juste donner un autre point de vue sur cette question au lecteur.

Eh bien, nous sommes allés sur une frénésie d'apprentissage apprentissage HTML, CSS, CSS sélecteurs, un langage merveilleux Javascript et JS libs, JQuery et YUI et créé le produit web à temps avec une interface graphique complète et la conformité des performances; et J'ai personnellement je suis heureux et l'équipe est ainsi que les utilisateurs.

D'autres équipes qui ont suivi la voie Vaadin ont également créé leurs produits à temps et je suppose qu'elles sont également heureuses.(Seulement ils ne connaissent pas la joie de JavAScript ils manquent :))