Devo usar o Vaadin Framework [fechado]

https://stackoverflow.com/questions/1183801

19-09-2019
|

Pergunta

Eu apenas tentei brincar com Estrutura Vaadin e me parece muito fácil de usar.Além disso, o que eu gosto em sua estrutura é que ela é construída sobre Kit de ferramentas da Web do Google (GWT).

O que você acha, devo continuar usando esse framework ou é melhor continuar com o GWT?

Solução

Ei. Como aviso, trabalho para a empresa que desenvolve Vaadin.

O Vaadin usa o GWT de uma maneira que possui um conjunto de componentes pré -compilados no GWT. Obviamente, você pode fazer seus próprios componentes, se quiser. No entanto, o conjunto de componentes é bastante completo e geralmente pode ser personalizado para sua própria necessidade. Isso significa que você não precisa recompilar seu código de Java para JavaScript toda vez que alterar seu aplicativo. Você apenas combina os componentes já disponíveis.

A estrutura é orientada ao servidor, portanto, toda a lógica é tratada no lado do servidor. Os componentes possuem duas partes, cliente e arquivo de servidor. O lado do cliente é apenas uma "exibição" dummy para o componente. Depois de interagir com ele, ele envia uma mensagem ao servidor de que este ou que foi pressionado/escrito/etc. O servidor decide o que deve ser feito. Isto é para aumentar a segurança, porque você não pode "hackear" a lógica, pois apenas uma pequena API destinada ao envio de solicitações está disponível no JavaScript. Isso pode ser, em alguns casos, um pouco de troca com a velocidade do aplicativo, mas não acho que seja tão ruim. Os piores saltos de velocidade geralmente são ida e volta de consulta de banco de dados e tal, o que não tem nada a ver com a escolha da estrutura da interface do usuário. A lentidão das demos, conforme sugerida, pode ser porque você está longe do servidor ou há um usuário alto no momento. Experimente em um ambiente próprio, feche o aplicativo final do seu aplicativo, para ver como ele é executado. Existem algum aplicativo pronto que você pode implantar para testá -lo.

Eu acho que a escolha se resume ao que você está tentando fazer. O Vaadin é bom para aplicativos da Web, pois você pode criar um aplicativo Java normal e fazer a interface da web dinâmica com facilidade. Se você está fazendo algo mais tradicional, onde os usuários apenas visualizam a página - mais do que interage ativamente, o Vaadin não é o melhor caminho a percorrer. Vá com outras estruturas gratuitas, como Rails ou uma estrutura PHP, etc. Acho que você está fazendo mais um aplicativo, sugerindo que está usando o GWT agora, para que Vaadin seja bom.

Faça mais perguntas, aqui, nos fóruns do Vaadin ou no canal IRC #Vaadin @Freenode e talvez alguém possa lhe dar mais motivos para ou por que não usar o Vaadin.

Outras dicas

Depois de quase 1,5 ano, desenvolvendo um aplicativo GWT não tão grande, usando todas as melhores práticas que aprendi com a última E/S do Google, como MVP, Eventbus, CommandPattern, etc. Eu digo isso do fundo do meu coração: depois de passar dias tentando Para fazer as coisas funcionarem da maneira que minha equipe e cliente queriam tecnicamente e visualmente, mesmo após o lançamento do Uibinder, Vaadin veio a mim como uma luz no final do túnel.

Depois de escrever quase mil ações de caldeira para o padrão de comando, outros mil apresentadores e vistas e outros mil manipuladores de eventos, etc. não precisando lidar com quase 75% dessas classes e ainda manter uma boa abordagem de padrão (complemento da AppFoundation), Um pouco de sobrecarga de rede é aceitável. Com Vaadin, pronto para uso, você obtém bons widgets, paginação, ligação de dados, layout infectativo. Tudo isso para quê? Algum mais consumo de memória no lado do servidor.

Acho que posso dizer que isso é aceitável porque não estou construindo o próximo Facebook ou algo assim. Ainda posso lidar com milhares de usuários simultâneos por servidor médio e ainda manter as ida e volta de baixa latência.

Com o Vaadin, posso criar um bom aplicativo com quase meia das linhas de código e o aplicativo ainda parece mais completo. :-)

!! ATUALIZAÇÃO 23 de fevereiro de 2011: Não posso enfatizar como alguém deve estar ciente das limitações de cada estrutura. Vaadin não é diferente. Deve -se estar ciente de que Vaadin abstrava qualquer forma de HTML ou JavaScript. Além disso, o HTML resultante é muito pesado e você deve cuidar da história do estado muda. Portanto, esteja ciente dessas despesas gerais ao criar seu projeto.

Isenção de responsabilidade:Não sou afiliado a nenhuma das bibliotecas mencionadas a seguir, mas conheço muito bem como contorná-las.

Assim como você, me deparei com este post ao pensar em qual pilha/estrutura usar para um novo projeto.Tive uma experiência sólida com o Play!(ok, em Scala, mas isso não é relevante aqui), mas os widgets atraentes e sua integração perfeita com o lado do servidor + o desenvolvimento do tipo Swing despertaram meu interesse.Isso foi no final de 2010, e como as respostas me convenceram a dar uma chance ao Vaadin, decidi voltar e escrever a resposta que gostaria de ler aqui, especialmente.já que a questão ainda é relevante hoje.Enquanto isso, Vaadin passou da versão 6 para 7 com algumas melhorias notáveis que eram necessárias, Play!passei da versão 1 para 2 e eu (+ uma pequena equipe) concluí um pequeno número de projetos de sucesso com ambos os frameworks.

Acho que a comparação é interessante porque ambos os frameworks

executado na JVM e pode aproveitar seu abundante ecossistema
não poderiam estar mais em desacordo em sua abordagem aos aplicativos da web e com o que você, como desenvolvedor, deve se preocupar e
em menor grau, como eles se relacionam com o Java EE.

Louvar

Em uma frase, se você acha atraente a ideia de portar um aplicativo de desktop para um navegador enquanto é completamente abstraído do mecanismo subjacente de solicitação/resposta HTTP, então Vaadin é provavelmente seu candidato para criar aplicativos da web.Sua abordagem de programação tipo Swing pode ser muito fácil para aqueles que estão mais satisfeitos com o baixo nível de HTML e JavaScript.Uma nova solicitação para seu aplicativo está de fato iniciando uma nova instância e o restante do fluxo depende de você e de sua lógica.Os links voltam aos bons e velhos botões de navegação e você fica livre para compor seus layouts usando os vários modelos integrados, sem precisar ajustar o HTML ou CSS.A API é geralmente bastante consistente e reconhecidamente bem documentada (o Livro de Vaadin é uma leitura obrigatória.Faça isso cuidadosamente, pois muitas coisas estão prontamente disponíveis, por exemplo.vinculando seus beans a componentes e validadores, ...).Os widgets possuem uma boa compatibilidade geral entre navegadores, garantindo assim um comportamento consistente de sua aplicação em uma ampla gama de clientes.

Verificação da realidade

Nos divertimos desenvolvendo e testando nossos aplicativos Vaadin.As coisas ficaram mais claras e diferenciadas quando lançamos a primeira versão e começamos a coletar feedback.Nós percebemos que na verdade, fomos tendenciosos em alguns aspectos fundamentais, a saber:

Em 201x, a maioria dos usuários tinha um longo histórico de uso da web e poucos deles quase não usam mais aplicativos de desktop.O ponto chave aqui é que os navegadores padronizaram a interação UX com links de hipertexto, botões voltar, avançar e recarregar, guias onipresentes e, às vezes, janelas, e a ideia básica de que a maioria das ações aciona uma solicitação HTTP e aguardará uma resposta.Este é o contrato implícito que os sites cumprem e em torno do qual são construídos.Portanto, não deveríamos ter ficado surpresos quando os usuários reclamaram que não conseguiam usar os botões voltar/avançar como estavam acostumados ou que as guias não funcionavam da maneira esperada.E nós concordamos.Quebramos o contrato invisível que vincula usuários e navegadores.Na verdade, nós mesmos estávamos implicitamente não usar nosso navegador com o aplicativo Vaadin da mesma forma que usamos com qualquer outro site.Claro, você pode voltar ao livro mencionado acima e ler atentamente sobre como replicar uma experiência de navegação na web com fragmentos de URL e verá que na verdade é mais complicado do que o previsto porque os aplicativos Vaadin têm estado.Além disso, os paradigmas MVC ou MVP são impostos apenas vagamente ao desenvolvedor, em contraste com o Play!onde praticamente não há outra opção.Não leve isso a sério, mas seu cérebro está acostumado com a tela branca brilhante mostrada por uma fração de segundo após uma mudança de página.Quando os usuários clicam e esperam ser direcionados para uma nova página, o navegador reconhece mostrando a ampulheta (ou variações dela).Com AJAX, as solicitações são colocadas nos bastidores.Hoje existem lugares onde pequenos ataques AJAX, quase cirúrgicos, se tornaram a norma, mas ainda não para grandes atualizações da interface do usuário.
Aplicativos com estado trazem sua cota de desafios...e problemas.O balanceamento de carga (se você estiver preocupado) é mais complicado.O conceito de transação é totalmente diferente, pois as sessões Vaadin abrangem muitas solicitações e são, portanto, longas, em contraste com a abordagem baseada em REST, mas têm vida relativamente curta em termos de UX.Na verdade, não é incomum que os usuários voltem ao formulário que iniciaram horas atrás para terminar sua tarefa.Isso poderia, em teoria, funcionar com Vaadin também, mas você teria que manter as sessões vivas por muito, muito tempo com a memória bloqueada o tempo todo e pensar cuidadosamente sobre isso seria escalonável.Usuários concorrentes.

Páginas com estado também são mais difíceis de serem compartilhadas pelos usuários, muito menos favoritas (supondo que você tenha lidado com fragmentos de URL).
Por fim, compartilhamos a impressão de que a UI geralmente é mais lenta com a lógica no servidor.É claro que você sempre pode criar um widget carregado com JavaScript do lado do cliente para reduzir o número de viagens de ida e volta, mas inevitavelmente terá que fazer algumas atualizações da interface do usuário no servidor.O JS já é bastante pesado para interpretar na minha experiência e proporciona uma experiência menor em dispositivos móveis (conheço o TouchKit, mas ainda assim:Aplicativos HTML5 em dispositivos móveis simplesmente não servem para mim).Além disso, lembre-se de que o thread da UI fica ativo após a publicação de uma solicitação (ou seja,ação do usuário no lado do cliente, semelhante a obter atualizações da UI) e estará acessível a você por meio de vários ouvintes.No entanto, atualizar a UI a partir de threads em segundo plano é mais complicado (por exemplo,empurrando atualizações).Vaadin 7 melhorou a situação a este respeito, especialmente com relativamente HTML mais leve gerado.Melhorias significativas na reatividade da UI foram notadas simplesmente ativando a compactação HTTP.

Conclusão

Então paramos e nos perguntamos o que achamos tão atraente na abordagem Vaadin para começar.O desenvolvimento inicial foi relativamente tranquilo, produzindo resultados rápidos, mas retrabalhar alguns conceitos para acomodar as expectativas de UX da web nos deu uma forte impressão de estar nadando contra a maré.Concluímos que a ideia sedutora de ser abstraído (obscurecido?) do mecanismo de solicitação/resposta HTTP provou ser uma faca de dois gumes que revelou a real incompatibilidade de impedância entre aplicativos da web e aplicativos de desktop.

Em vez de fingir que a web é mais uma camada, sentimos fortemente que se deveria abraçar a forma como ela funciona e isso começa com um aplicativo centrado em URL (conforme imposto por Rails/Django/Play).Você provavelmente já ouviu alguém dizer que os dados sobrevivem ao aplicativo.Hoje em dia, os dados são referidos por recursos de URL, então pode-se dizer com segurança que os URLs sobrevivem aos dados.Afinal, são eles que as pessoas marcam, não são?Assim, a separação básica de interesses também deverá aplicar-se a este nível.Provavelmente é por isso que a web se tornou tão popular.Então, revisitamos nosso aplicativo para estruturá-lo mais em torno de um controlador central que responde às ações à la Play feitos em caminhos de recursos distintos.

Por enquanto estamos mantendo nossos aplicativos Vaadin, mas devido a algumas dessas restrições e à mudança fundamental de paradigma não iniciaremos novos projetos com ele.No entanto, tiro o chapéu para a equipe que construiu uma estrutura web Java 360° tecnicamente coerente, coesa e bem documentada, exigindo muito pouco conhecimento do funcionamento interno da web.No lado positivo, eles até apoiam sua estrutura com uma empresa que vende serviços de consultoria.Sou grato pela experiência e por como ela me fez reavaliar meus pontos de vista sobre aplicações web.Acompanharei de perto sua evolução, mas definitivamente precisamos de mais controle e granularidade.

Esperamos que um dia o Vaadin se liberte de toda a arquitetura Servlet da qual depende para ter seu próprio servidor HTTP.Melhor ainda seria um design MVC mais profundamente enraizado na estrutura.Mas isso é um tanto improvável no futuro próximo, pois parece ter encontrado um nicho lucrativo entre os gorilas corporativos experientes de Java que apenas confiam em EE.Brilhe.

DR:Acho que Vaadin não entende o que são webapps e, mais importante, como eles deveriam se comportar.Já era hora de os programadores adotarem a web e a forma como os usuários interagem com ela (ou seja,botão voltar, botão recarregar, guias e favoritos).Quanto mais próximo um aplicativo da web estiver das solicitações HTTP e da semântica (verbos), maior será a probabilidade de ele atender às expectativas do usuário.E isso é fundamental.

EDITAR:Se você tiver alguma experiência em Python, eu recomendo experimentar o Flask também para ter uma ideia da programação de aplicativos da web centrada em URL e baseada em REST.

EDITAR 2:Se por algum motivo você achar que deve usar uma estrutura full-stack do tipo Vaadin, experimente o Meteor.É uma estrutura baseada em JavaScript (tanto frond quanto back-end) que roda em Node.js com comunicação assíncrona ocorrendo por meio de WebSocket (portanto, latência menor que solicitação/resposta) e é reativa por padrão.Várias coisas que não gosto em Vaadin foram abordadas em Meteor.Por exemplo, a lógica para atualizações da UI é executada no cliente, o que o torna muito mais responsivo do que no Vaadin.O pessoal das comunidades JavaScript e Java não se cruzam muito, mas quando ouvi falar disso pela primeira vez, o paralelo com Vaadin me impressionou imediatamente.Atualmente goza de bastante impulso na comunidade por razões semelhantes às que tornaram Vaadin popular, ou seja.a capacidade de criar aplicativos da web semelhantes a desktop.Experimente se você também percebeu que Java não pertence muito ao cenário de futuros aplicativos da web ou se você está cansado daqueles longos ciclos de implantação quando basta atualizar.Mas pense duas vezes antes de vincular um aplicativo inteiro a apenas uma biblioteca.

A conversa usual sobre Vaadin diz respeito ao conjunto de widgets e preocupações com a comunicação de ida e volta entre o cliente e o servidor.

Mas, na minha opinião, isso ignora o aspecto mais significativo (talvez revolucionário) de Vaadin: elimina completamente a tarefa de projetar e implementar a comunicação cliente-servidor que geralmente é necessária para aplicativos Ajax (o "A" e "X" no Ajax) .

Com o Vaadin, você pode esquecer completamente os DTO (objetos de transferência de dados), problemas de segurança baseados em protocolo, exceções de carregamento preguiçoso de hiberna, etc.

Você está, em certo sentido, apenas escrevendo um aplicativo de desktop Java Swing antigo comum, apenas você está usando um kit de ferramentas de interface do usuário diferente do Swing.

Pela minha experiência, o GWT exige muito código de caldeira e lento ao construir uma interface do usuário complicada e rica. Normalmente, lidamos com modelos de aplicativos bastante complexos que contêm muitos objetos de domínio persistíveis. Para trazer todos esses dados para o cliente, você precisará introduzir um modelo de cliente separado e fornecer mecanismo de conversão de dados. Usamos o Dozer para esse fim e leva muito tempo para mapear cada um arquivado, criar conversores personalizados e testar tudo isso.

Por outro lado, se não cair em excesso de engenharia e se o aplicativo não for muito complicado, você pode se beneficiar de utilizar os recursos do cliente e ter menos carga no servidor. Dessa forma, você pode minimizar drasticamente a comunicação com o servidor e obter software muito mais responsivo.

Vadin parece muito desenvolvedor se debatendo :) Mas eu tenho um pouco de medo de "ataque maciço do Ajax" ao servidor. Tenho experiência em ZK e, muitas vezes, enfrentamos os problemas de desempenho quando uma operação trivial na interface do usuário funciona devagar porque requer comunicação com o servidor.

O wicket é outra boa estrutura, mas é mais adequada para sites. Pode funcionar com e sem Ajax, pode ser indexado pelos mecanismos de pesquisa. E a coisa mais atraente que lida com o código HTML limpo - sem tags personalizadas, sem estruturas de controle, separação estrita de preocupações e apenas namigs wicketid específicos para componentes.

Depende principalmente de suas necessidades:

Se você precisar de um aplicativo super rápido e simples - use GWT e utilize os recursos do cliente
Se o seu aplicativo for bastante complexo, Vaadin parece ser a melhor opção
Se o seu aplicativo for público e você precisar de uma capacidade de indexá -lo para SEO do que a escolha do wicket.

O problema é que, para o desenvolvimento sério, você não pode esquecer nada, muito menos DTOs. Estou abandonando a costura e o conceito de interface do usuário do servidor só porque desejo um controle mais fino sobre o que está acontecendo no arame .. Problema de Vaadin para mim é precisamente isso, tendo estado no lado do servidor.

Havia "preocupações" sobre o wicket usando sessões para gerenciar estados de componentes e escalabilidade semelhante aos argumentos sobre o processamento do Vaadin e do servidor. Aprendi nos últimos 10 anos que a comunidade Java geralmente está errada sobre como medir o potencial de uma estrutura da web (entre outras coisas). Do JSF a Grails, geralmente são necessárias algumas centenas de GB de memória e pelo menos uma dúzia de arquivos JAR de código aberto com funcionalidade sobreposta e ineficiente para executar um aplicativo de produção. Olhe ao redor e você verá a maioria das empresas de hospedagem na web não oferecer uma opção Java prática por causa do caminho irregular que as tecnologias Java tomadas para estruturas da web. O GWT 2.1 ainda é uma dor de usar devido à velocidade de compilação e está ficando sério com as tabelas de MVP e dados que deveriam estar lá desde o início. Eu gosto do wicket, mas Vaadin parece promissor ... mas sabendo como as estruturas do Java vão, tenho certeza de que elas se atirarão no pé em algum momento, mas duvido que seja por causa do processamento do lado do servidor pesado.

Para construir interface do usuário de boa aparência, eu diria que esse seria o caminho a percorrer. Além disso, está muito bem documentado.

Eu o uso há algumas semanas e eu verdade Como até agora. O código é sólido, os documentos de construção boa e muito lógica, os resultados finais são excelentes.

Estou adorando isso em combinação com o Hibernate para resolver todo o tédio do banco de dados.

Além disso - fácil de implantar (com o tomcat, você pode fazer upload de um único arquivo .war através da interface da web, não poderia ser mais fácil)

Também vale a pena considerar Apache Wicket como uma alternativa forte para estruturas de interface do usuário da web java orientadas a componentes. Vaadin parece ótimo e não quero prejudicar essa discussão, mas a escolha é uma coisa boa. Existem alguns exemplos com a fonte vinculada à página inicial e ainda mais no site Wicketstuff, e o excelente livro de Manning forma uma ótima documentação de terceiros.

Dê uma olhada na construção da Demo Vaadin com Maven:http://asolntsev.blogspot.com/2009/11/vaadin-demo.html

Eu pensei que Wicket era o caminho a seguir, até que tentei fazê -lo funcionar com eficiência e iniciar uma depressão (piada). Então, mudei para o GWT, o que parecia ótimo, mas há muuuito código de placa de caldeira para escrever e a documentação não é tão ótima ... -> A luz veio de Vaadin: simples, operacional, sem insetos até agora ... !!!

Em nossa empresa, que é predominantemente uma grande casa de Java SW (entre outras coisas), chegou a nós a chance de criar um novo produto baseado na Web. Era um conjunto de produtos e havia muitas equipes em três países desenvolvendo isso. Quando se tratava de nossa equipe, tive a opção de usar o Vaadin para o benefício de alavancar nossa experiência de desenvolvimento de Java. Pensei no Google para me ajudar em minha decisão. Eu também li este post; No entanto, escolhi contra o uso de Vaadin, embora muitas outras equipes tenham escolhido Vadin. Abaixo estão os motivos de um e -mail que envio naquele momento antes de iniciar o produto (para Vaadin ou não). Isso é da minha visão pessoal e desconfiança das estruturas em geral está sempre em mim em vários graus. Então, só queria dar outra opinião sobre essa pergunta ao leitor.

Bem, fomos a um aprendizado de aprendizado HTML, CSS, CSS Selectors, um maravilhoso idioma JavaScript e JS Libs, JQuery e Yui e criamos o produto da Web a tempo com GUI completa e conformidade de desempenho; E eu, pessoalmente, estou feliz e a equipe é e também os usuários.

Outras equipes que foram o Vaadin Way também criaram seus produtos a tempo e acho que são igualmente felizes (só eles não conhecem a alegria do JavaScript que estão perdendo :)).

Como alguém disse, todas as abstrações são abstrações com vazamentos e, quando tiveram que migrar de Vaadin 6 para Vaadin 7, eles tiveram que fazer um pouco de trabalho e levou mais tempo do que qualquer um pensava; Embora, é claro, eles tenham conseguido triturar e fins; Ainda houve um pouco de atraso devido a isso. Também acho que havia algum problema com o InvientCharts Addon, o que não estava apoiando o Vaadin 7, fazendo com que as equipes comprassem ($$) os gráficos de Vaadin relacionados e a mudança para isso ....

Para Vaadin ou não

Com o Vaadin, parece que o JavaScript subjacente, o HTML e o CSS são gerados dinamicamente a partir de um aplicativo do tipo Java Swing. Do ponto de vista purista tendencioso e provavelmente bobo, esse slogan "vou gerar código para você" não dá um bom cheiro de design. A menos que você precise de uma abstração, por que se amarrar com mais uma estrutura. Como em qualquer estrutura de geração de código, ela deve funcionar melhor para a abstração que o vaadin tinha em mente, mas não muito flexível; Sinto que, se fizermos a tecnologia da Web, é melhor fazer nas ferramentas e idiomas dos quais a tecnologia despertou - a saber, html, css e bibliotecas JavaScript/JavaScript, em vez de depender de outro nível de abstração - a estrutura Vaadin. Isso pode parecer ingênuo para um desenvolvedor especialista em GWT ou Vaadin, pois acho que os complicados do Google geram o JavaScript mais otimizado do que os seus codificados à mão, ajudam a gerenciar o código melhor entre várias equipes etc., mas principalmente ao desenvolver aplicativos da Web bastante biggish), melhor desenvolvedor Produtividade, depuração mais fácil etc. No entanto, escrever componentes em Java para Vaadin e, em seguida, converter automaticamente em JS, não me sinto certo, pois muitos de nossos desenvolvedores nunca aprenderão uma linguagem de programação muito importante - JavaScript para o desenvolvimento da Web (e ganhando tração rapidamente no Lado do servidor - node.js). Ao confiar em estruturas para acertar seu JavaScript, pois você nunca se destacará nesse idioma. Eu acho que para uma empresa baseada em produtos, é importante aprender em primeira mão o idioma da Web. Como alguém comentou, Java se tornou como o COBOL do ano passado e é imperativo que a competência se acumule para aprender outros idiomas importantes, como o JavaScript. No entanto, tendo trabalhado no JS pelo pequeno tempo que tenho, notei que, se codificarmos com alguma disciplina (padrão de módulo), teste toda a lógica - unidade JavaScript - jstestdriver e executar jshint, é uma linguagem bastante poderosa para trabalhar com a qual trabalhar E a produtividade fica melhor que o Java, uma vez aprendido. Além disso, a maioria dos componentes importantes - o OpenLayers é escrito em JS e, se você precisar estendê -los ou trabalhar com a melhor maneira, precisa conhecer JavaScript, ou, nesse assunto Ao usar Vaadin e estruturas, a longo prazo, talvez o uso de JavaScript seja importante?

Estou usando Vaadin também. Embora o aplicativo não seja grande, o que eu realmente gostei da experiência foi que a API era consistente, geralmente bem documentada e, dado que eu estava desenvolvendo com uma nova ferramenta, pude criar coisas para um muito O cliente exigente no mesmo, ou em alguns casos, melhores prazos do que as ferramentas que eu usei antes.

Muito poucos problemas. O único agora é que o cliente insiste em usar o IE 7 (não pergunte) e alguns dos colys mais sofisticados não funcionam totalmente 100% em um componente de addon (gráfico).

BTW, também não trabalho para Vaadin :-)

Eu tentei Wicket e Vaadin e, se você realmente tenta os dois por algum tempo, com em um mês você saberá que Vaadin é o caminho a percorrer e não o postigo, ponto final. - dheeraj g

Analisamos o wicket onde trabalho, mas encontramos em vez de 9.000 arquivos, poderíamos ter mais de 30.000. Temos quase 1.000 telas com nosso aplicativo principal de serviços financeiros e, embora o wicket pareça ótimo, é extremamente difícil converter nosso código de struts 1.3 em wicket. Nosso arquiteto fez um projeto POC e apenas três telas adicionaram várias centenas de classes (muitas são para reutilização). Também é difícil protoype uma tela com wicket, pois seu HTML deve corresponder ao código Java e vice-versa.

Vaadin parece promissor, mas será uma venda difícil para a equipe.

PS Não importa o quão grande seja uma estrutura, ninguém aprenderá se não for usado no setor. O Wicket existe há algum tempo, mas poucas empresas o usam. A maioria dos desenvolvedores com quem converso está preocupada em aprender uma nova estrutura que é inútil em um currículo.

O principal é que o Vaadin usa design semelhante a um swing e ajuda que eu iniciei em Java usando o swing.

Eu usei Vaadin para desenvolver um GiftVisor na empresa em que trabalho (não Vaadin;).

O Vaadin permite criar aplicativos da Web com componentes componentes reais.

Se você está preocupado com a ida e volta do cliente-servidor para cada clique, tenho isso a dizer: criei um botão MouseOver que altera a aparência do botão em sim, MouseOver. Para isso, a estrutura precisa ir ao servidor e voltar. E funciona rápido o suficiente na IMO. Ver http://www.cadeau.nl/sophie Para verificar o que quero dizer.

Eu gosto de Vaadin, ele suita minhas necessidades e facilita o desenvolvimento da web.

Atenciosamente, Rob.

Comecei com Vaadin há apenas dois dias e pude criar um pequeno aplicativo CRUD no OSGI completo com modularidade, ligação de dados e serviços OSGI para persistência. Uma coisa muito boa é que minha interface do usuário completa são apenas 118 linhas de código e suporta operações completas do CRUD para uma estrutura de feijão Java simples.

Também é bom que Vaadin funcione perfeitamente em Osgi. Já é um pacote e encontrei uma pequena ponte de Neil Bartlet que torna Vaadin extremamente fácil de usar no OSGI.

Ver Lista de tarefas Vaadin Exemplo

Não me importo de usar estados no lado do servidor. Serve seu propósito. Com a computação em nuvem, o armazenamento e a largura de banda estão se tornando baratos. Mas sim, eu posso ver seu ponto de uma boa perspectiva de design, especialmente se você quiser restabelecer seu aplicativo. Mas acredito que há mais profissionais do que contras em relação a Vaadin e similares. Uma coisa importante, você não precisa ajustar muito sobre seus aplicativos da web para um navegador específico, vamos chamá-lo, ou seja, para meandros JavaScript/CSS-especialmente se você for orientado para o back-end como eu. Todos os seus aplicativos da Web se tornam compatíveis com o navegador sem ter que preocupar nada. Lembre -se de que o tempo do desenvolvedor é mais caro que o de armazenamento e largura de banda. Essa é a minha opinião. =)

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow