Devrais-je utiliser le Framework Vaadin [fermé]
https://stackoverflow.com/questions/1183801
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'ai juste essayé de jouer avec Vaadin Cadre et il me semble très facile à utiliser.En Plus de ce que j'aime à propos de son cadre, c'est qu'il est construit sur le haut de Google Web Toolkit (GWT).
Que pensez-vous, dois-je continuer à utiliser ce cadre ou il est préférable de coller avec GWT?
La solution
Hey. Comme un avertissement, je travaille pour la société de développement Vaadin.
Vaadin utilise GWT d'une manière qu'il a un ensemble de composants précompilés dans GWT. Vous pouvez, bien sûr, faire plus vos propres composants si vous voulez ainsi. Cependant, l'ensemble des composants est assez complet, et peut souvent être personnalisé pour vos propres besoins. Cela signifie que vous n'avez pas à recompiler votre code de Java JavaScript chaque fois que vous changez votre application. Vous venez de combiner les composants déjà disponibles ensemble.
Le cadre est entraîné serveur, de sorte que toute la logique est traitée sur le côté serveur. Les composants comporte deux parties, le client et le fichier du serveur. Le côté client est juste un mannequin « vue » pour le composant. Une fois que vous interagissez avec elle, il envoie un message au serveur ou que ce qui a été pressé / écrit / etc. Le serveur décide alors ce qu'il faut faire. Ceci est pour plus de sécurité, parce que vous ne pouvez pas « pirater » la logique que seule une petite API destinée à envoyer des requêtes est disponible dans le javascript. Cela peut être dans certains cas, un peu hors du commerce avec la vitesse de l'application, mais je ne pense pas que ce soit un si mauvais. Pire ralentisseurs sont généralement db allers-retours de requête et autres, qui n'a rien à voir avec le choix du cadre de l'interface utilisateur. Lenteur des démos comme suggéré peut-être parce que vous êtes loin du serveur ou il y a un grand utilisateur a frappé au moment. Essayez-le dans un environnement propre, fermez la l'application finale de votre application, pour voir comment il exécute. Il y a une application prête que vous pouvez simplement déployer pour le tester.
Je suppose que le choix se résume à ce que vous essayez de faire. Vaadin est bon pour les applications Web, que vous pouvez construire une application Java normale et faire l'interface utilisateur Web dynamique pour facilement. Si vous faites quelque chose de plus d'un site Web traditionnel, où les utilisateurs vues la page - plus interagit activement avec elle, alors Vaadin est pas la meilleure façon d'aller. Allez avec d'autres cadres libres comme des rails ou un cadre de php, etc. Je pense que vous êtes plus à faire une demande comme vous le suggérez que vous utilisez maintenant GWT, donc Vaadin devrait être bon.
Demandez plus de questions, ici, sur les forums Vaadin ou sur le canal irc #vaadin @freenode et peut-être quelqu'un peut vous donner plus de raisons pour expliquer pourquoi ou pourquoi ne pas utiliser Vaadin.
Autres conseils
Après près de 1,5 année à l'élaboration d'un pas si énorme demande GWT, en utilisant toutes les meilleures pratiques que j'ai appris de la dernière Google I / O comme MVP, EventBus, CommandPattern, etc. Je dis cela du fond de mon cœur: après passer des jours à essayer de faire avancer les choses fonctionnent à la façon dont mon équipe et le client voulait à 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 actions boilerplate pour motif de commande, un autre millier de présentateurs et des vues et un autre millier de gestionnaires d'événements, etc .. Ne pas avoir à faire face à près de 75% de ces classes et en maintenant une bonne approche de motif (appfoundation add- on), un peu au-dessus du réseau est acceptable. Avec Vaadin, hors-the-box, vous obtenez de bons widgets, la pagination, la liaison de données, layouting impeccable. Tout cela pour quoi? Encore plus la consommation de mémoire du côté serveur.
Je pense que je peux dire ce qui est acceptable parce que je ne suis pas construire le prochain Facebook ou quelque chose. Je peux encore gérer des milliers d'utilisateurs simultanés par serveur moyen et maintenant encore allers-retours à faible latence.
Avec Vaadin, je peux construire une belle application avec presque la moitié des lignes de code et encore l'application semble plus complète. : -)
!! 23 Février Mise à jour 2011: Je ne peux pas souligner comment il faut être conscient des limites de chaque cadre. Vaadin est pas différent. Il faut savoir que les résumés Vaadin loin de toute forme de HTML ou JavaScript. En outre, le résultat HTML est très lourd et vous devez prendre soin de l'état de l'histoire vous change. Alors, soyez au courant de ces frais généraux lorsque vous créez votre projet.
Avertissement:Je suis affilié à aucun des bibliothèques mentionnés ci-après (mais sais mon chemin autour d'eux assez bien.
Comme vous, je suis tombé sur ce post lors de la réflexion qui pile/cadre à utiliser pour un nouveau projet.J'ai eu une solide expérience avec le Jeu!(ok, en Scala, mais ce n'est pas pertinente ici), mais le poids des widgets et leur intégration transparente avec le côté serveur + le Swing comme le développement a piqué mon intérêt.C'était à la fin de 2010, et que 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 d'actualité aujourd'hui.Pendant ce temps, Vaadin est allé à partir de la version 6 à 7 avec quelques améliorations notables qui ont été nécessaires, Jouer!est passé de la version 1 à la 2 et I (+ une petite équipe) a réalisé un petit nombre de projets couronnés de succès avec les deux cadres.
Je pense que la comparaison est intéressante parce que les deux cadres
- exécution de la JVM et de tirer parti de ses abondantes de l'écosystème
- ne pouvait pas être plus en désaccord dans leur approche pour les applications web et ce que vous, en tant que développeur faut s'en préoccuper, et
- dans une moindre mesure, la façon dont ils se rapportent à Java EE.
Louange
En une phrase, si vous trouvez l'idée du portage d'une application de bureau à un navigateur tout en étant complètement abstraction de la base de la requête HTTP/mécanisme de réponse convaincante, alors Vaadin est probablement ce que votre candidat pour faire des applications web.Son Swing comme approche pour la programmation peut être un jeu d'enfant pour ceux qui sont plus heureux loin de la basse-levelness de HTML et de JavaScript.Une nouvelle demande de votre application est en effet le démarrage d'une nouvelle instance et le reste de l'écoulement est à vous et à votre logique.Liens revenir à la bonne vieille de boutons pour la navigation et vous êtes libre de composer vos mises en page à l'aide des nombreux modèles intégrés sans jamais être nécessaire de modifier le HTML ou le CSS.L'API est généralement tout à fait cohérente et, certes, bien documenté (l' Livre de Vaadin est obligatoire de lire.Le faire à fond, comme beaucoup de choses sont facilement disponibles, par exemple.la liaison de vos haricots pour les composants et les validateurs, ...).Les widgets ont une bonne compatibilité inter-navigateur, assurant ainsi la cohérence du comportement de votre application sur un large éventail de clients.
Vérification de la réalité
Nous avons eu un bon temps à développer et tester nos Vaadin apps.Les choses sont devenues plus claires et plus nuancée quand nous avons lancé la première version et a commencé à recueillir des commentaires.Nous nous sommes rendu compte que nous avons eu effectivement un parti pris assez façons fondamentales, à savoir:
En 201x, la plupart des utilisateurs ont une longue histoire de l'utilisation du web, et peu d'entre eux utilisent peu les applications de bureau en plus.Le point clé ici est que les navigateurs normalisé le UX de l'interaction avec des liens hypertexte, un arrière, un avant et un bouton de rechargement, omniprésent onglets et parfois des fenêtres, et l'idée de base que la plupart des actions de déclencher une requête HTTP et attend une réponse.C'est le contrat implicite que les sites web se conformer à et autour de laquelle ils sont construits.Par conséquent, nous ne devrions pas être surpris lorsque les utilisateurs se sont plaints qu'ils ne pouvaient pas utiliser les boutons précédent et suivant qu'ils ont été utilisés pour, ou que les onglets ne fonctionnent pas de la manière prévue.Et nous sommes convenus.Nous avons cassé l'invisible contrat liant les utilisateurs et les navigateurs.En fait, nous étions nous-mêmes implicitement ne pas utiliser notre navigateur avec le Vaadin application de la façon dont nous avons utilisé avec n'importe quel autre site web.Bien sûr, vous pouvez revenir en arrière à ce livre et de le lire attentivement sur la réplication d'une expérience de navigation web avec l'URL de fragments, et vous verrez que c'est en fait plus compliqué que prévu parce que Vaadin applications sont stateful.En outre, le MVC ou MVP paradigmes ne sont que faiblement imposées sur le développeur, en revanche pour Jouer!où il n'y a pratiquement pas d'autre option.Ne prenez pas cela à la légère, mais votre cerveau est utilisé pour le blanc lumineux de l'écran affiché pendant une fraction de seconde à la suite d'un changement de page.Lorsque les utilisateurs cliquent sur et s'attendre à être pris une nouvelle page, le navigateur reconnaît en montrant le sablier (ou une de ses variantes).Avec l'AJAX, les demandes sont placés derrière les coulisses.Aujourd'hui, il existe des endroits où de petites, presque chirurgicale AJAX grèves sont devenues la norme, mais pas pour les grands de l'INTERFACE utilisateur mise à jour.
Dynamique des applications apportent leur lot de défis...et les ennuis.L'équilibrage de la charge (si vous êtes concerné) pour l'un est plus compliqué.La notion de transaction est tout à fait différente que Vaadin sessions couvrent de nombreuses demandes et sont, par conséquent, de long en contraste avec RESTE approche, mais relativement de courte durée, en termes de 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, le travail avec Vaadin trop, mais vous auriez à garder les sessions en vie pour un long, long temps avec la mémoire bloqué tout le temps et réfléchissez bien à bien ce serait échelle w.r.t.utilisateurs simultanés.
Stateful pages sont également plus difficile pour les utilisateurs à partager, laissez seul signet (c'est en supposant que vous avez fait affaire avec l'URL de fragments).
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é avec du JavaScript côté client pour diminuer le nombre d'aller-retours, mais vous devrez inévitablement à faire quelques mises à jour de l'INTERFACE utilisateur sur le serveur.Le JS est déjà assez lourd à interpréter dans mon expérience, et fait d'une moindre expérience sur des appareils mobiles (je suis au courant de TouchKit, mais encore:Les applications HTML5 sur des appareils mobiles n'est pas suffisant pour moi).Aussi, gardez à l'esprit que le thread d'INTERFACE utilisateur est actif après une demande est publiée (ie.action de l'utilisateur sur le côté client, semblable à tirer de l'INTERFACE utilisateur des mises à jour) et sera accessible par le biais de différents auditeurs.Toutefois, la mise à jour de l'INTERFACE utilisateur de threads d'arrière-plan est plus compliqué (par exemple.pousser les mises à jour).Vaadin 7 amélioration de la situation à cet égard, et en particulier avec relativement plus léger du code HTML généré.D'importantes améliorations à l'INTERFACE utilisateur de réactivité ont été perceptibles en tournant simplement sur la compression HTTP.
Conclusion
Donc, nous avons fait une pause et je me demandais ce que nous avons trouvé intéressant dans le Vaadin approche pour commencer.Le développement initial avait été relativement douceur de roulement en produisant des résultats rapides, mais à retravailler quelques concepts pour accueillir web UX attentes nous a donné une forte impression de nager à contre-courant.Nous avons conclu que le séduisant les idée d'être absorbées (obscurci?) à partir de la requête/réponse HTTP mécanisme a donné une épée à double tranchant qui a dévoilé la véritable différence d'impédance entre les applications web et les applications de bureau.
Au lieu de faire semblant de croire que le web est encore une autre couche, nous avons fortement ressenti que l'on doit embrasser la façon dont il fonctionne et cela commence avec le fait d'avoir une URL centrée sur demande (imposées par les Rails/Django/Jouer).Vous avez probablement entendu quelqu'un dire que les données survit à l'application.Aujourd'hui, les données sont visés par l'URL de ressources, donc on peut dire que les Url survivre données.Après tout, ils sont ce que les gens signet, n'est-ce pas?Donc de base de la séparation des préoccupations devraient s'appliquer également à ce niveau.C'est sans doute pourquoi le web est devenu si populaire en premier lieu.Donc, nous avons revisité notre application à la structure plus autour d'un contrôleur de répondre à des actions à la Jouer faite sur des ressources, des chemins d'accès.
Pour l'instant, nous gardons notre Vaadin des applications, mais en raison de certaines de ces contraintes et le changement fondamental de paradigme nous ne serons pas en commencer de nouveaux projets avec elle.Toutefois chapeau à l'équipe qui a construit techniquement cohérent, uniforme et bien documenté 360° framework Java pour le web ne nécessitant que très peu de connaissances sur le web rouages.Sur l'envers, ils ont même leur cadre avec une société qui vend des services de consultation.Je suis reconnaissant pour l'expérience et pour la façon dont il m'a fait réévaluer mon point de vue sur des applications web.Je vais surveiller de près son évolution, mais nous avons certainement besoin de plus de contrôle et de granularité.
J'espère qu'un jour Vaadin permettra de libérer de lui-même à partir de l'ensemble de la Servlet de l'architecture sur laquelle elle s'appuie pour avoir son propre serveur HTTP.Le mieux serait un MVC conception plus profondément enracinés dans le cadre.Mais c'est peu probable dans un avenir prévisible, puisqu'il semble avoir trouvé une niche lucrative parmi assaisonné d'entreprise Java gorilles qui ne jure que par EE.Briller sur.
TL;DR:Je pense que Vaadin manque le point de ce que les webapps sont et, plus important encore, comment ils devraient se comporter.Il est temps que les programmeurs ont embrassé le web et la façon dont les utilisateurs interagissent avec elle (c'est à dire.bouton précédent, bouton de rechargement, des onglets et des favoris).Le plus proche d'une application web de bâtons pour les requêtes HTTP et de la sémantique (les verbes), le plus elle est susceptible de correspondre aux attentes de l'utilisateur.Et c'est la clé.
MODIFIER:Si vous avez tout de Python, je recommande fortement d'essayer Flacon de façon à obtenir une saveur de url-centric, RESTE à base de programmation d'applications web.
EDIT 2:Si pour une raison quelconque vous sentez que vous devez utiliser une pile de Vaadin-comme cadre, puis donner le Météore de l'essayer.C'est un JavaScript (les deux frondes et back-end) cadre que s'exécute sur l'Node.js avec communication asynchrone survenant par WebSocket (donc plus petit temps de latence qu'requête/réponse), et il est réactif par défaut.Un certain nombre de choses que je n'aime pas dans Vaadin ont été abordées dans le Météore.Par exemple, la logique de l'INTERFACE utilisateur exécution des mises à jour sur le client qui le rend beaucoup plus sensible que dans Vaadin.Les gens dans le JavaScript et Java communautés ne coupe pas beaucoup mais quand j'ai d'abord entendu parler de lui, le parallèle avec Vaadin m'a frappé immédiatement.Il jouit actuellement tout à fait un peu de dynamisme dans la communauté pour des raisons semblables à celles qui ont fait de Vaadin populaire, c'est à dire.la capacité de faire un ordinateur de bureau comme des applications web.Ne lui donner un essai si vous avez également pris conscience du fait que Java n'appartient pas beaucoup dans l'image de l'avenir des applications web ou si vous êtes fatigué de ces longues déployer des cycles lors de la frappe d'actualisation est tout ce qu'il doit prendre.Mais réfléchir à deux fois avant d'attacher l'ensemble d'une application à une seule bibliothèque.
La discussion habituelle au sujet Vaadin concerne l'ensemble des widgets et des soucis sur la communication aller-retour entre le client et le serveur.
Mais à mon avis, cela ne tient pas le plus important aspect (peut-être révolutionnaire) de Vaadin: elle élimine complètement la tâche de concevoir et mettre en œuvre la communication client-serveur qui est habituellement nécessaire pour les applications AJAX (le « A » et « X » dans Ajax).
Avec Vaadin, vous pouvez oublier complètement de DTO (les objets de transfert de données), les problèmes de sécurité à base de protocole, Hibernate exceptions de chargement paresseux, etc.
Vous êtes en quelque sorte en train d'écrire une application de bureau Swing régulière vieux Java, que vous utilisez une boîte à outils de l'interface utilisateur différente de Swing.
D'après mon expérience GWT exige beaucoup de code et lent boilerplate lors de la construction UI complecated et riche. Habituellement, nous traitons avec des modèles d'application très complexes qui possède de nombreux objets de domaine persistables. Pour mettre toutes ces données au client, vous aurez besoin d'introduire le modèle client distinct et fournir le mécanisme de conversion de données. Nous avons utilisé Dozer à cette fin et il faut beaucoup de temps à la carte ont déposé chacun, créer des convertisseurs personnalisés et de tester tout ce genre de choses.
D'autre part, si ne tombez pas dans overengineering et si l'application est pas très compliqué, vous pouvez prendre un avantage d'utiliser les ressources du client et ont moins de charge sur le serveur. De cette façon, vous pouvez considérablement réduire la communication avec le serveur et obtenir un logiciel beaucoup plus réactif.
Vadin semble développeur très frinedly :) Mais je un peu peur de « attaque AJAX massive » au serveur. J'ai l'expérience dans ZK et souvent nous avons été confrontés aux problèmes de performance lors d'une opération triviale sur l'interface utilisateur fonctionne lente, 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 oeuvre dans le code HTML propre -. Pas de balises personnalisées, pas de structures de contrôle, la séparation stricte des préoccupations et seulement namigs de wicketid spécifiques pour les composants
Il dépend surtout de vos besoins:
- Si vous avez besoin l'application super rapide et simple - utiliser GWT et utiliser les ressources du client
- Si votre application est assez complexe que Vaadin semble être la meilleure option
- Si votre application est publique et vous avez besoin d'une capacité à indexer pour le référencement que choisi Wicket.
La chose est, pour le développement sérieux, vous ne pouvez pas oublier quoi que ce soit, et encore moins dtos .. Je suis amerrissage forcé la couture, et côté serveur concept ui juste parce que je souhaite un contrôle plus précis sur ce qui se passe sur le fil .. Vaadin de problème pour moi est précisément que, ayant l'état sur le côté serveur ..
Il y avait « préoccupations » au sujet de l'aide Wicket sessions pour gérer les états de composants et d'évolutivité similaires aux arguments sur Vaadin et le traitement côté serveur. Je l'ai appris au cours des 10 dernières années que la communauté Java est généralement mal sur la façon de mesurer un potentiel de cadre 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 fonctionnalité chevauchement et inefficace pour obtenir un fonctionnement de l'application de production. Regardez autour de vous et vous verrez la plupart des sociétés d'hébergement Web ne proposent pas une option java pratique en raison du chemin des technologies Java erratiques ont pris pour frameworks web. GWT 2.1 est encore une douleur à utiliser en raison de la vitesse de compilation et il est juste devient sérieux avec des tables et MVP données qui auraient dû être là depuis le début. J'aime Wicket mais Vaadin regarde prometteur ... mais de savoir comment frameworks Java vont, je suis sûr qu'ils vont se tirer une balle dans le pied à un moment donné, mais je doute que ce sera à cause du traitement côté serveur lourd.
Pour la construction d'une bonne recherche de l'interface utilisateur de, je dirais que ce serait la voie à suivre. De plus, il est très bien documenté.
Je l'ai utilisé pendant deux ou trois semaines et je vraiment comme jusqu'à présent. Code est solide, docs une nouvelle bonne, la construction très logique, les résultats finaux sont excellents.
Je suis amoureuse en combinaison avec Hibernate pour trier toutes les bases de données ennui.
Plus - facile à déployer (Avec Tomcat, vous pouvez simplement télécharger un seul fichier .WAR 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
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, qui avait l'air très bien, mais il y a beaucoup soooo code plaque de chaudière pour écrire et la documentation est pas terrible ... -> La lumière est venue de Vaadin: simples, opérationnelles, pas de bugs à ce jour ... !!!
Dans notre société qui est principalement une grande maison Java SW (entre autres), il est venu sur nous une chance de créer un nouveau product.It était basé sur le Web un ensemble de produits et il y avait beaucoup d'équipes dans trois pays en développement, cela. Quand il est venu à notre équipe, j'ai eu le choix d'utiliser Vaadin au profit de tirer parti de notre développement java experience.I recherche Google pour me aider dans ma décision. Je lis aussi ce poste; Cependant, je choisi de ne pas utiliser Vaadin bien que beaucoup d'autres équipes ont choisi Vadin. Voici les raisons d'un courrier que j'envoie à ce moment-là avant de commencer sur le produit (à Vaadin ou non). Ceci est de mon point de vue personnel et méfiance à l'égard 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 un apprentissage HTML frénésie d'apprentissage, CSS, CSS Selectors, une langue merveilleuse JavaScript et libs JS, JQuery et YUI et créé le produit Web dans le temps avec une interface graphique complète et la conformité de la performance; et moi-même, je suis heureux et l'équipe est aussi bien, ainsi que les utilisateurs.
D'autres équipes qui ont fait le chemin Vaadin ont également créé leurs produits dans le temps et je pense sont tout aussi heureux. (Seulement, ils ne connaissent pas la joie de JAVASCRIPT ils manquent :)).
Comme quelqu'un l'a dit, les abstractions sont des abstractions qui fuient et quand ils ont dû migrer de Vaadin 6 à 7 Vaadin ils ont dû faire un peu de tout à fait nouveau travail et il a fallu plus de temps que quelqu'un a pensé; mais bien sûr, ils ont réussi à moudre et finsh il; Il y avait encore un peu de retard dû à this.Also Je suppose qu'il y avait un problème avec addon InvientCharts qui Vaadin ne soutenait pas 7 entraînant les équipes d'acheter ($$) les graphiques Vaadin liés addon et changement pour que ....
Pour Vaadin ou non
Avec Vaadin il semble que le JavaScript, HTML et CSS sous-jacente sont générées dynamiquement à partir d'une application Swing Java type. D'un point de vue puriste biaisé et probablement stupide, un tel slogan « Je vais générer le code pour vous » ne donne pas une bonne odeur de conception. À moins que vous avez besoin d'une abstraction pourquoi attacher avec un autre cadre. Comme pour tout cadre de production de code, il devrait mieux pour l'abstraction Vaadin avait à l'esprit, mais pas très flexible; Je pense que si nous faisons la technologie web, il est préférable de le faire dans les outils et langages d'où la technologie a suscité - à savoir, HTML, CSS et JavaScript / bibliothèques JavaScript plutôt que de se fier à un autre niveau d'abstraction - le cadre Vaadin. Cela peut se sentir naïf à un expert développeur GWT ou Vaadin comme je suppose que les observants Google génèrent le JavaScript le plus optimisé que ceux qui vous sont codés à la main,, aide à gérer le code mieux entre plusieurs équipes, etc (mais surtout le développement d'applications web assez biggish), meilleur développeur la productivité, le débogage plus facile, etc. Cependant l'écriture des composants en Java pour Vaadin et auto conversion à JS est je me sens pas bien dans ce que beaucoup de nos développeurs ne seront jamais apprendre un langage de programmation très important - JavaScript pour le développement web (et gagner la traction rapide sur le côté serveur - Node.js ). Lorsqu'ils se fondent sur les cadres pour obtenir votre JavaScript droite alors vous ne serez jamais exceller dans cette langue. Je suppose que pour une entreprise de produit, il est important d'apprendre de première main la langue du Web au lieu. Comme quelqu'un a commenté Java est devenu comme le COBOL de l'année et il est yester impératif pour construire des compétences pour apprendre d'autres langues importantes comme JavaScript. Toutefois, après avoir travaillé dans JS pour le petit temps que je l'ai, je l'ai remarqué que si on code avec une certaine discipline (modèle de module), tester toute logique - unité JavaScript - JSTestDriver et exécuter JSHint, il est un langage assez puissant pour travailler avec et la productivité va mieux que Java une fois qu'il est appris. Aussi la plupart des composants importants par exemple - OpenLayers sont écrits en JS et si vous avez besoin d'étendre ces ou work avec optimale que vous devez savoir JavaScript, ou pour cette matière de puissantes bibliothèques comme d3.js Donc en bref si il y a beaucoup d'avantages à utiliser Vaadin et cadres, à long terme, peut-être en utilisant JavaScript est important?
J'utilise Vaadin aussi bien. Bien que la demande est grande, ce que j'ai vraiment aimé l'expérience était que l'API était cohérente, généralement bien documenté et étant donné que je développais un nouvel outil, j'ai pu manivelle des choses pour un très client exigeant dans le même ou, dans certains cas, de meilleurs délais que les outils que j'utilisé avant.
Très peu de questions. Le seul est en ce moment le client insiste sur l'utilisation de IE 7 (ne demandez pas) et certains des bonbons pour les yeux colombophile ne fonctionne pas tout à fait 100% dans un composant addon (cartographie).
BTW je ne travaille pas pour Vaadin soit: -)
Je l'ai essayé et Wicket Vaadin à la fois et si vous essayez vraiment à la fois pendant un certain temps, avec dans un mois, vous saurez que Vaadin est la voie à suivre et non Wicket, période. - Dheeraj G
Nous avons examiné Wicket où je travaille, mais nous avons trouvé au lieu de 9000 fichiers, nous pourrions avoir plus de 30.000. Nous avons près de 1000 écrans avec notre application de services financiers de base et bien que Wicket ressemble beaucoup, il est extrêmement difficile de convertir notre code Struts 1.3 à Wicket. Notre architecte a fait un projet POC et à seulement 3 écrans ajouté plusieurs centaines de classes (beaucoup sont pour la réutilisation). Il est également difficile de Protoype un écran avec Wicket depuis votre code html doit correspondre au code Java et vice-versa.
Vaadin semble prometteur, mais il sera difficile à vendre à l'équipe.
P.S. Peu importe à quel point un cadre est, personne n'apprendra si elle n'est pas utilisé dans l'industrie. Wicket a été autour pendant un certain temps encore très peu d'entreprises l'utilisent. La plupart des développeurs que je parle avec sont concernés par l'apprentissage d'un nouveau cadre qui ne sert à rien sur un curriculum vitae.
L'essentiel est Vaadin utilise le design comme swing et aide que j'ai commencé en Java en utilisant Swing.
Je l'ai utilisé Vaadin pour développer une giftadvisor à l'entreprise où je travaille (pas Vaadin;).
Vaadin vous permet de créer des applications Web Swinglike réel à base de composants.
Si vous êtes préoccupé par aller-retour client-serveur pour chaque clic que j'ai dit ceci: J'ai créé un bouton qui change le mouseover regard du bouton oui, mouseover. Pour cela, le cadre doit aller au serveur et à l'arrière. Et cela fonctionne assez vite imo. Voir http://www.cadeau.nl/sophie pour vérifier ce que je veux dire.
J'aime Vaadin, il suites à mes besoins et webdevelopment fait un jeu d'enfant.
Cordialement, Rob.
J'ai commencé avec Vaadin il y a seulement deux jours et a été en mesure de construire une petite application CRUD sur OSGi complète avec la modularité, la liaison de données, services OSGi pour la persistance. Une chose vraiment intéressante est que mon interface utilisateur complète est seulement 118 lignes de code et prend en charge les opérations complètes de CRUD pour une structure simple de haricot java.
Il est aussi agréable que Vaadin fonctionne parfaitement dans OSGi. Il est déjà un paquet et je l'ai trouvé un petit pont de Neil Bartlet qui rend Vaadin extrêmement facile à utiliser dans OSGi.
Je ne l'esprit en utilisant les états du côté du serveur. Il sert son but. Avec Cloud Computing de stockage et la bande passante De nos jours sont de plus en plus pas cher. Mais oui, je peux voir votre point d'une bonne perspective de conception, surtout si vous voulez RESTify votre application. Mais je crois qu'il ya plus d'avantages que d'inconvénients en ce qui concerne Vaadin et similaires. Une chose importante, vous ne devez modifier beaucoup de choses sur votre web-apps pour un navigateur spécifique permet de l'appeler IE, pour subtilités Javascript / CSS - surtout si vous êtes orienté vers l'arrière-plan comme moi. Tous vos webapps devient compatible à travers le navigateur sans avoir à se soucier de rien. Rappelez-vous le temps de développement est plus coûteux que celui du stockage et la bande passante. Thats my opinion. =)
