Devrais-je utiliser le framework Vaadin
Je viens d'essayer de jouer avec Cadre Vaadin et il me semble très facile à utiliser. De plus, ce que j'aime de son cadre est qu'il est construit sur Google Web Toolkit (GWT) .
Que pensez-vous, devrais-je continuer à utiliser ce cadre ou s'il vaut mieux rester avec GWT?
Hey. Par mise en garde, je travaille pour la société en développement Vaadin.
Vaadin utilise GWT de manière à disposer d'un ensemble de composants précompilés dans GWT. Vous pouvez bien sûr créer vos propres composants si vous le souhaitez. Cependant, l'ensemble des composants est assez complet et peut souvent être personnalisé pour vos propres besoins. Cela signifie que vous ne devez pas recompiler votre code à partir de Java en JavaScript chaque fois que vous modifiez votre application. Vous combinez simplement les composants déjà disponibles.
La structure étant gérée par le serveur, toute la logique est gérée côté serveur. Les composants ont deux parties, le fichier client et le fichier serveur. Le côté client est juste une "vue" fictive pour le composant. Une fois que vous avez interagi avec elle, il envoie un message au serveur indiquant que ceci ou cela a été pressé/écrit/etc. Le serveur décide alors de ce qui doit être fait. Ceci pour une sécurité accrue, car vous ne pouvez pas "pirater" la logique car seule une petite API destinée à envoyer des demandes est disponible dans le javascript. Dans certains cas, cela peut être un léger compromis avec la vitesse de l’application, mais je ne pense pas que ce soit un problème. Les pires ralentisseurs sont généralement des allers-retours de requêtes de base de données, ce qui n’a rien à voir avec le choix du cadre d’interface utilisateur. La lenteur des démonstrations suggérée peut être due au fait que vous êtes loin du serveur ou que le nombre d'utilisateurs touché est élevé. Essayez-le dans votre propre environnement, fermez l’application finale de votre application pour voir ses performances. Il existe des applications prêtes à l'emploi que vous pouvez simplement déployer pour les tester.
Je suppose que le choix se résume à ce que vous essayez de faire. Vaadin convient aux applications Web, car vous pouvez créer une application normale Java et créer facilement une interface utilisateur Web dynamique. Si vous faites quelque chose de plus traditionnel, où les utilisateurs ne voient que page - plus qu’interagit activement avec lui, alors Vaadin n’est pas la meilleure solution. Allez-y avec d’autres frameworks gratuits tels que Rails ou un framework php, etc. Je pense que vous faites plus de choses une application comme vous suggérez que vous utilisez GWT maintenant, alors Vaadin devrait être bon.
Posez plus de questions, ici, sur les forums de Vaadin ou sur le canal irc #vaadin @freenode et peut-être que quelqu'un peut vous expliquer plus en détail pourquoi ou pourquoi ne pas utiliser Vaadin.
Après presque un an et demi de développement d’une application GWT pas si énorme, utilisant les meilleures pratiques que j’avais apprises lors du dernier I/O de Google, telles que MVP, EventBus, CommandPattern, etc. Je le dis du fond du cœur: après avoir passé des jours à essayer pour que tout se passe bien, visuellement et techniquement, de la part de mon équipe et de mon client, même après la sortie d'UiBinder, Vaadin m'est apparu comme une lumière au bout du tunnel.
Après avoir écrit près d'un millier d'actions standard pour le modèle de commande, un autre millier de présentateurs et de vues, un autre millier de gestionnaires d'événements, etc. N'ayant pas à traiter avec près de 75% de ces classes et conservant toujours une bonne approche de modèle (appfoundation add-on), un peu de surcharge du réseau est acceptable. Avec Vaadin, prêt à l'emploi, vous obtenez de bons widgets, une pagination, une liaison de données, une mise en page sans faille. Tout ça 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 du genre. 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 application Nice avec près de la moitié de lignes de code et l’application semble plus complète. :-)
!! MISE À JOUR DU 23 FÉVRIER 2011: Je ne saurais trop insister sur la manière de prendre conscience des limites de chaque framework. Vaadin n'est pas différent. Il faut savoir que Vaadin supprime toute forme de HTML ou de JavaScript. En outre, le code HTML résultant est très lourd et vous devez gérer vous-même les changements d'état de l'historique. 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 entre elles.
Comme vous, je suis tombé sur ce message lorsque je me suis demandé quelle pile/quel cadre utiliser pour un nouveau projet. J'ai eu une solide expérience avec Play! (ok, à Scala, mais ce n'est pas pertinent ici) mais les widgets convaincants et leur intégration transparente avec le côté serveur + le développement de Swing ont piqué mon intérêt. C'était fin 2010, et comme les réponses m'ont convaincu d'essayer Vaadin, j'ai décidé de revenir et d'écrire la réponse que j'aurais aimé lire ici, en particulier. comme la question est toujours d'actualité aujourd'hui. Pendant ce temps, Vaadin est passé de la version 6 à la version 7 avec quelques améliorations notables, Play! est passé de la version 1 à la version 2 et j'ai (+ une petite équipe) complété un petit nombre de projets réussis avec les deux cadres.
Je pense que la comparaison est intéressante parce que les deux cadres
- fonctionne sur la JVM et peut tirer parti de son écosystème abondant
- ne pourrait pas être plus en contradiction dans leur approche des applications Web et ce que vous, en tant que développeur, devriez vous soucier de, et
- dans une moindre mesure, leur lien avec Java EE.
Louange
En un mot, si l'idée de porter une application de bureau sur un navigateur tout en étant complètement abstraite du mécanisme de requête/réponse HTTP sous-jacent vous convainc, alors Vaadin est probablement votre candidat pour la création d'applications Web. Son approche de la programmation, similaire à Swing, peut être un jeu d'enfant pour ceux qui sont les plus heureux, loin du faible niveau de HTML et de JavaScript. Une nouvelle requête de 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 de navigation et vous êtes libre de composer vos mises en page à l'aide des nombreux modèles intégrés sans avoir à modifier le code HTML ou CSS. L'API est généralement assez cohérent et certes bien documenté (le Livre de Vaadin est une lecture obligatoire. Faites-le soigneusement car de nombreux éléments sont facilement disponibles, par exemple, la liaison de vos haricots aux composants et aux validateurs, ... ). Les widgets offrent une bonne compatibilité globale entre les navigateurs, garantissant 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 avons publié la première version et commencé à recueillir des commentaires. Nous nous sommes rendus compte que nous avions été biaisés de manière assez fondamentale, à savoir:
En 201x, la plupart des utilisateurs utilisaient Internet depuis longtemps, et rares sont ceux qui utilisent à peine les applications de bureau. Le point clé ici est que les navigateurs ont normalisé l’interaction UX avec des liens hypertextes, un bouton Précédent, un bouton Suivant et un bouton de rechargement, des onglets omniprésents et parfois des fenêtres, ainsi que l’idée de base selon laquelle la plupart des actions déclenchent une connexion HTTP. demande et attendra 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 de ne pas pouvoir utiliser les boutons Précédent/Suivant comme ils étaient habitués ou que les onglets ne fonctionnaient pas comme prévu. Et nous avons accepté. Nous avons rompu le contrat invisible liant les utilisateurs et les navigateurs. En fait, nous étions nous-mêmes implicitement n'utilisions pas notre navigateur avec l'application Vaadin de la manière dont nous l'avons utilisé avec tout autre site Web. Bien sûr, vous pouvez revenir au livre susmentionné et en lire plus sur la réplication d’une expérience de navigation Web avec des fragments d’URL et vous verrez qu’il est en réalité plus complexe que prévu , car les applications Vaadin sont stateful . De plus, les paradigmes MVC ou MVP ne sont imposés que vaguement au développeur, contrairement à Play! où il n'y a pratiquement aucune autre option. Ne prenez pas cela à la légère, mais votre cerveau est habitué à l’écran blanc brillant affiché pendant une fraction de seconde après un changement de page. Lorsque les utilisateurs cliquent et s'attendent à recevoir une nouvelle page, le navigateur en accuse réception en affichant le sablier (ou ses variantes). Avec AJAX, les demandes sont placées dans les coulisses. Il existe aujourd'hui des endroits où de petites frappes presque chirurgicales AJAX sont devenues la norme, mais pas encore pour les mises à jour majeures de l'interface utilisateur.
Les applications stateful apportent leur lot de défis ... et de problèmes. L'équilibrage de charge (si vous êtes concerné) pour l'un est plus compliqué. Le concept de transaction est totalement différent car les sessions de Vaadin couvrent de nombreuses demandes et sont donc longues, contrairement à l'approche basée sur REST, mais leur durée de vie est relativement courte en termes d'UX. En effet, il n'est pas rare que les utilisateurs reviennent à un formulaire qu'ils ont commencé heures auparavant pour terminer leur tâche. En théorie, cela pourrait aussi fonctionner avec Vaadin, mais il faudrait maintenir les sessions en vie très longtemps avec la mémoire bloquée pendant tout ce temps et bien réfléchir à la possibilité que cela évolue. utilisateurs concurrents.
Les pages avec état sont également plus difficiles à partager pour les utilisateurs, sans parler des signets (en supposant que vous ayez traité des fragments d'URL).
Enfin, nous partageons l’impression que l’interface utilisateur est généralement plus lente avec la logique sur le serveur. Bien sûr, vous pouvez toujours créer un widget chargé avec du code JavaScript côté client pour réduire le nombre d'allers-retours, mais vous devrez inévitablement effectuer des mises à jour de l'interface utilisateur sur le serveur. D'après mon expérience, le JS est déjà assez lourd à interpréter et offre une expérience moins longue sur les appareils mobiles (je connais TouchKit, mais ça ne fonctionne pas: les applications HTML5 sur les appareils mobiles ne me suffisent pas). De plus, n'oubliez pas que le thread d'interface utilisateur est actif après l'envoi d'une demande (action de l'utilisateur côté client, similaire à l'extraction des mises à jour de l'interface utilisateur) et qu'il vous sera accessible via différents écouteurs. Cependant, la mise à jour de l'interface utilisateur à partir de threads d'arrière-plan est plus compliquée (par exemple, l'envoi de mises à jour). Vaadin 7 a toutefois amélioré la situation à cet égard, 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é remarquées en activant simplement la compression HTTP.
Conclusion
Nous nous sommes donc arrêtés et nous nous sommes demandé ce que nous avions trouvé si attrayant dans l'approche de Vaadin. Le développement initial avait été une conduite relativement douce donnant des résultats rapides, mais la retouche de certains concepts pour répondre aux attentes de Web UX nous donnait une forte impression de nage à contre-courant. Nous avons conclu que l’idée séduisante d’être abstraite (occultée?) Du mécanisme de requête/réponse HTTP s’était révélée être une arme à double tranchant révélant le déséquilibre réel entre impédance des applications Web et des applications de bureau.
Plutôt que de prétendre que le Web est encore une couche supplémentaire, nous avons fortement estimé qu'il fallait adopter son fonctionnement , ce qui commence par 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 des ressources d'URL, ce qui permet de dire en toute sécurité que les URL survivent à plus de la donnée Après tout, ils sont ce que les gens signet, n'est-ce pas? La séparation fondamentale des préoccupations devrait donc 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 effectuées sur des chemins de ressources distincts.
Pour l'instant, nous maintenons nos applications Vaadin, mais en raison de certaines de ces contraintes et du changement fondamental de paradigme, nous ne pourrons pas commencer de nouveaux projets avec. Cependant, l'équipe qui a construit un framework web 360 ° Java techniquement cohérent, cohérent et bien documenté ne nécessite que très peu de connaissances du fonctionnement interne du Web. Sur le plan positif, ils ont même renforcé leur cadre avec une entreprise vendant des services de conseil. Je suis reconnaissant de l'expérience et de la manière dont cela m'a permis de réévaluer mes points de vue sur les applications Web. Je suivrai de près son évolution, mais nous avons certainement besoin de plus de contrôle et de granularité.
Espérons que Vaadin se libèrera un jour de toute l'architecture Servlet sur laquelle il s'appuie pour disposer de son propre serveur HTTP. Mieux encore, une conception MVC plus enracinée dans le cadre. Mais cela est quelque peu improbable dans un avenir prévisible, car il semble avoir trouvé un créneau lucratif parmi les entreprises expérimentées Java gorilles qui ne jurent que par EE. Briller sur.
TL; DR : Je pense que Vaadin manque le sens de ce que sont les webapps et, plus important encore, leur comportement. Il est temps que les programmeurs adoptent le Web et la manière dont les utilisateurs l’interagissent (bouton Précédent, bouton de rechargement, onglets et signets, par exemple). Plus une application Web s'en tient aux requêtes HTTP et à la sémantique (verbes), plus elle a de chances de répondre aux attentes des utilisateurs. Et c'est la clé.
[~ # ~] éditer [~ # ~] : Si vous avez une expérience de Python, je vous recommande fortement d'essayer Flask également pour obtenir un aperçu de la programmation d'applications Web REST centrée sur l'URL.
EDIT 2 : Si pour quelque raison que ce soit, vous estimez que vous devez utiliser un framework de type Vaadin complet, testez alors Meteor. C'est un framework basé sur JavaScript (à la fois frond et back end) qui fonctionne sur Node.js avec une communication asynchrone via WebSocket (donc une latence inférieure à celle de la requête/réponse) et qui est réactif par défaut. Un certain nombre de choses que je n'aime pas à Vaadin ont été abordées 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 lorsque j'en ai entendu parler pour la première fois, le parallèle avec Vaadin m'a immédiatement frappé. Il bénéficie actuellement d'un certain élan dans la communauté pour des raisons analogues à celles qui ont rendu Vaadin populaire, c'est-à-dire. la possibilité de créer des applications Web de type bureau. Essayez si vous vous rendez compte que Java n’appartient pas beaucoup à l’image des futures applications Web ou si vous en avez marre de ces longs cycles de déploiement lorsqu’un rafraîchissement est suffisant. Mais réfléchissez-y à 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 client et serveur.
Mais à mon avis, cela néglige l’aspect le plus significatif (peut-être révolutionnaire) de Vaadin: il élimine complètement la tâche de conception et de mise en oeuvre de la communication client-serveur qui est généralement requise pour les AJAX applications (les " Un "et" X "en AJAX).
Avec Vaadin, vous pouvez complètement oublier les objets de transfert de données (DTO), les problèmes de sécurité basés sur les protocoles, les exceptions de chargement paresseux d'Hibernate, etc.
Dans un certain sens, vous écrivez simplement une ancienne Java Swing de bureau classique), vous seul utilisez un kit d’outils d’interface utilisateur différent de Swing.
D'après mon expérience, GWT nécessite beaucoup de code passe-partout et ralentit lors de la construction d'une interface utilisateur riche et riche. Généralement, nous traitons avec des modèles d'application assez complexes contenant de nombreux objets de domaine persistants. Pour apporter toutes ces données au client, vous devez introduire un modèle de client distinct et fournir un mécanisme de conversion des données. Nous avons utilisé Dozer à cette fin et il faut beaucoup de temps pour mapper chaque fichier classé, créer des convertisseurs personnalisés et tester tout cela.
D'un autre côté, si vous ne tombez pas dans l'ingénierie excessive et si l'application n'est pas très compliquée, vous pouvez tirer parti de l'utilisation des ressources client et réduire la charge sur le serveur. De cette manière, vous pouvez considérablement réduire la communication avec le serveur et obtenir un logiciel beaucoup plus réactif.
Vadin semble très développeur très gentiment :) Mais je crains un peu "d'attaques massives AJAX"). J'ai de l'expérience en ZK et nous avons souvent été confrontés à des problèmes de performances lorsqu L'interface utilisateur fonctionne lentement car elle nécessite une communication avec le serveur.
Wicket est un autre bon cadre, mais il convient mieux aux sites Web. Il peut fonctionner avec et sans AJAX, peut être indexé par les moteurs de recherche. Et la chose la plus attrayante concerne le code HTML propre: pas de balises personnalisées, pas de structures de contrôle, une séparation stricte des problèmes et uniquement des noms de poupées spécifiques aux composants.
Cela dépend surtout de vos besoins:
- Si vous avez besoin d'une application simple et rapide - utilisez GWT et utilisez les ressources du client
- Si votre application est assez complexe, Vaadin semble être la meilleure option.
- Si votre application est publique et que vous avez besoin d'une capacité d'indexation pour le référencement, choisissez Wicket.
Le problème est que, pour un développement sérieux, vous ne pouvez rien oublier, sans parler de dtos .. je perds la couture et le concept de l'interface utilisateur côté serveur simplement parce que je souhaite un contrôle plus précis de ce qui se passe sur le réseau .. Le problème de vaadin pour moi est précisément cela, avoir l'état sur le côté serveur ..
Wicket a eu des "préoccupations" en utilisant des sessions pour gérer les états et l’évolutivité des composants, similaires aux arguments concernant 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 de mesurer le potentiel d'un framework Web (entre autres). 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 superposées et inefficaces pour faire fonctionner une application de production. Regardez autour de vous et vous verrez la plupart des sociétés d’hébergement Web ne proposent pas de solution pratique Java à cause du chemin erratique Java technologies ont été utilisées pour les frameworks Web). GWT 2.1 est toujours difficile à utiliser à cause de la vitesse de compilation et cela commence à devenir sérieux avec MVP et les tables de données qui auraient dû être là. Dès le début. J'aime Wicket mais Vaadin a l'air prometteur ... mais sachant comment les frameworks Java vont, je suis sûr qu'ils se tireront une balle dans le pied à un moment donné, mais je doute qu'ils le soient en raison du traitement lourd côté serveur.
Pour construire de belles interfaces utilisateur, je dirais que ce serait la voie à suivre. En plus, c'est très bien documenté.
Cela vaut également la peine d’être envisagé Apache Wicket comme solution de rechange efficace aux frameworks Web UI orientés vers les composants Java). le choix est une bonne chose: il existe quelques exemples avec des sources liées en dehors de la page d’accueil, et plus encore sur le site WicketStuff, et l’excellent livre de Manning constitue une excellente documentation de tiers.
Je l'utilise depuis quelques semaines et je l'aime vraiment jusqu'à présent. Le code est solide, la construction est très bonne, très logique, les résultats sont excellents.
J'adore combiner cela avec Hibernate pour résoudre tous les ennuis de base de données.
Plus - facile à déployer (avec Tomcat, vous pouvez simplement télécharger un seul fichier .WAR via l'interface Web, rien de plus simple)
Dans notre société, qui est principalement une grande Java SW, nous avons eu l’occasion de créer un nouveau produit basé sur le Web. C’était un ensemble de produits et il y avait de nombreuses équipes dans trois pays. développer cela. 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 fait appel à 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 de nombreuses autres équipes aient choisi Vadin. Vous trouverez ci-dessous les raisons d'un courrier que j'ai envoyé à ce moment-là avant de commencer le produit (À Vaadin ou Non). C’est de mon point de vue personnel et la méfiance à l’égard des cadres en général est toujours en moi à des degrés divers. Je voulais donc simplement donner un autre point de vue sur cette question au lecteur.
Nous nous sommes lancés dans l’apprentissage du langage HTML, CSS, des sélecteurs CSS, un merveilleux langage JavaScript et JS Libs, JQuery et YUI et avons créé le produit Web à temps, avec une interface graphique complète et une performance conforme; et personnellement, je suis heureux et l’équipe est aussi bien que les utilisateurs.
Les autres équipes qui ont suivi la voie de Vaadin ont également créé leurs produits à temps et je suppose qu’elles sont tout aussi heureuses.
Comme quelqu'un l'a dit, toutes les abstractions sont des abstractions qui fuient et quand ils ont dû migrer de Vaadin 6 à Vaadin 7, ils ont dû faire quelques retouches et cela a pris plus de temps que prévu. bien sûr, ils ont réussi à moudre et à finir; Il y avait toujours un peu de retard à cause de cela. De plus, j'imagine qu'il y avait un problème avec l'addon InvientCharts qui ne supportait pas Vaadin 7, ce qui a amené les équipes à acheter ($$) l'addon connexe de Vaadin Charts et à modifier cela ....
To Vaadin or Not
Avec Vaadin, il semble que les codes JavaScript, HTML et CSS sous-jacents soient générés dynamiquement à partir d'une application de type Java Swing. D'un point de vue puriste partial et probablement stupide, un tel slogan "Je générerai du code pour vous" ne donne pas une bonne odeur de conception. À moins que vous n'ayez besoin d'une abstraction, pourquoi vous associer à un autre cadre. Comme avec tout framework de génération de code, il devrait fonctionner mieux pour l'abstraction que Vaadin avait à l'esprit, mais pas très flexible. Je pense que si nous utilisons la technologie Web, il est préférable d’utiliser les outils et les langages qu’elle a créés - à savoir les bibliothèques HTML, CSS et JavaScript/JavaScript plutôt que de compter sur un autre niveau d’abstraction - le framework Vaadin. Cela peut sembler naïf à un développeur expert de GWT ou de Vaadin, car je suppose que les développeurs de Google génèrent le code JavaScript le plus optimisé par rapport à vos codes codés à la main, permet de mieux gérer le code entre plusieurs équipes, etc. productivité, débogage plus facile, etc. Cependant, écrire des composants dans Java pour Vaadin, puis effectuer une conversion automatique en JS, n’est pas correct, car bon nombre de nos développeurs n’apprendront jamais un langage de programmation très important - JavaScript pour le développement Web ( et gagner du terrain rapidement du côté serveur - Node.js). Lorsque vous utilisez des frameworks pour obtenir votre code JavaScript, vous ne pourrez jamais utiliser Excel dans cette langue. Je suppose que pour une entreprise axée sur les produits, il est important d’apprendre le langage du Web à la place. Comme quelqu'un l'a commenté, Java est devenu comme le COBOL de l'année précédente et il est impératif que les compétences acquises soient apprises pour apprendre d'autres langages importants tels que JavaScript. Cependant, ayant travaillé dans JS aussi peu que moi, j’ai remarqué que si nous codons avec une certaine discipline (modèle de module), testons toute la logique - unité JavaScript - JSTestDriver, et exécutons JSHint, c’est un langage assez puissant pour travailler avec , et la productivité est meilleure que Java une fois qu’elle est apprise. Par exemple, la plupart des composants importants - OpenLayers sont écrits en JS et si vous avez besoin de les étendre ou de travailler de manière optimale, vous devez connaître JavaScript, ou même des bibliothèques puissantes comme D3.js. Bref, il y a beaucoup d'avantages En utilisant Vaadin et les frameworks, à long terme, utiliser JavaScript est-il important?
Je pensais que Wicket était la voie à suivre, jusqu'à ce que j'essaye de le faire fonctionner efficacement et que je commence une dépression (blague). Ensuite, je suis passé à GWT, qui avait fière allure, mais il y a tellement de code à écrire pour la chaudière et la documentation n’est pas si géniale ... -> La lumière venait de Vaadin: simple, opérationnelle, pas de bugs jusqu’à présent ... !!!
jetez un oeil à la démo de Vaadin avec Maven: http://asolntsev.blogspot.com/2009/11/vaadin-demo.html
J'utilise aussi Vaadin. Bien que l'application ne soit pas volumineuse, ce qui m'a vraiment plu dans l'expérience, c'est que l'API était cohérente, généralement bien documentée et, étant donné que je développais avec un nouvel outil, je pouvais créer des choses pour un très = client exigeant dans les mêmes délais, voire dans certains cas, de meilleurs délais que ceux utilisés auparavant.
Très peu de problèmes. Le seul actuellement, c’est que le client insiste pour utiliser IE 7 (ne demandez pas) et une partie de la friandise fantaisiste ne fonctionne pas totalement à 100% dans un composant addon (cartographie).
Au fait, je ne travaille pas pour Vaadin non plus :-)
J'ai essayé Wicket et Vaadin tous les deux et si vous essayez vraiment les deux pendant un certain temps, avec dans un mois, vous saurez que Vaadin est la voie à suivre et non Wicket, point. - Dheeraj G
J'ai commencé avec Vaadin il y a à peine deux jours et j'étais capable de construire une petite application CRUD sur OSGi avec modularité, liaison de données et services OSGi pour la persistance. Une chose vraiment intéressante est que mon interface utilisateur complète n’est que de 118 lignes de code et prend en charge les opérations CRUD complètes pour une structure de bean simple Java.
C’est également agréable que Vaadin fonctionne parfaitement dans OSGi. C'est déjà un paquet et j'ai trouvé un petit pont de Neil Bartlet qui rend extrêmement facile l'utilisation de vaadin dans OSGi.
Nous avons examiné Wicket où je travaille mais nous avons trouvé au lieu de 9 000 fichiers, nous pourrions en avoir plus de 30 000. Nous avons près de 1 000 écrans avec notre application de services financiers de base et bien que Wicket ait l'air génial, il est extrêmement difficile de convertir notre code Struts 1.3 en Wicket. Notre architecte a réalisé un projet POC et trois écrans seulement ont ajouté plusieurs centaines de classes (beaucoup sont à réutiliser). Il est également difficile de protéger un écran avec Wicket car votre code HTML doit correspondre au code Java et inversement.
Vaadin semble prometteur, mais ce sera difficile à vendre à l'équipe.
P.S. Peu importe la qualité du cadre, personne ne l'apprendra s'il n'est pas utilisé dans l'industrie. Wicket existe depuis un certain temps, mais très peu d'entreprises l'utilisent. La plupart des développeurs avec lesquels je discute sont intéressés à apprendre un nouveau cadre qui est inutile sur un CV.
L’essentiel est que Vaadin utilise une conception semblable à Swing et cela a aidé que j’ai commencé à utiliser Java en utilisant Swing.
J'ai utilisé Vaadin pour développer un cadeau auprès de l'entreprise pour laquelle je travaille (pas Vaadin;).
Vaadin vous permet de créer de véritables applications Web Swinglike en composantes.
Si vous êtes préoccupé par les allers-retours client-serveur pour chaque clic, j’ai ceci à dire: j’ai créé un bouton mouseover qui modifie l’apparence du bouton sur yes, mouseover. Pour cela, le framework doit aller sur le serveur et inversement. Et ça marche assez vite imo. Voir http://www.cadeau.nl/sophie pour vérifier ce que je veux dire.
J'aime Vaadin, il répond à mes besoins et facilite le développement web.
Cordialement, Rob.
Cela ne me dérange pas d'utiliser des états du côté serveur. Il sert son but. Avec le cloud computing, la bande passante et le stockage de jour en jour deviennent peu coûteux. Mais oui, je peux comprendre votre point de vue du point de vue de la conception, en particulier si vous souhaitez réactiver votre application. Mais je pense qu’il ya plus d’avantages que d’inconvénients à Vaadin, etc. Une chose importante, vous n’aurez pas à peaufiner vos applications web pour un navigateur spécifique, appelons-le IE, pour les subtilités Javascript/CSS - surtout si vous êtes orienté vers le back-end comme moi. Toutes vos applications Web deviennent compatibles avec tous les navigateurs sans avoir à vous soucier de rien. Rappelez-vous que le temps consacré aux développeurs est plus coûteux que le stockage et la bande passante. Cest mon avis. =)