Quando não usar o Google Web Toolkit? [fechadas]

Estou pensando em usar o GWT em um grande projeto interno de desenvolvimento de aplicativos Web, a saber, a maior vantagem para mim é a compilação cruzada para Javascript que (pelo menos teoricamente) ajudaria minha equipe a reduzir o tamanho da pilha de tecnologia em um .

No entanto, tendo sido gravado antes (como a maioria dos desenvolvedores), eu gostaria de ouvir de programadores que realmente o utilizaram em problemas com o GWT que dificultariam ou limitariam o uso em um determinado domínio de problema.

Quais são os argumentos contra o uso do GWT e por quê?

Sou bom e mau em responder a essa pergunta - bom, porque realmente o usei antes, e ruim, por ter bastante experiência com HTML / CSS / JavaScript antes de trabalhar com o GWT. Isso me deixou enlouquecido ao usar o GWT de uma maneira que outros desenvolvedores Java que realmente não conhecem DHTML podem não ter.

O GWT faz o que diz - abstrai JavaScript e, até certo ponto, HTML em Java. Para muitos desenvolvedores, isso parece brilhante. No entanto, sabemos, como Jeff Atwood coloca, todas as abstrações são abstrações com falha (vale a pena ler se considerarmos o GWT). Com o GWT, isso introduz especificamente os seguintes problemas:

Usar HTML no GWT é uma porcaria.

Como eu disse, até certo ponto, até abstrai o HTML. Parece bom para um desenvolvedor Java. Mas isso não. HTML é um formato de marcação de documento. Se você quisesse criar objetos Java para definir um documento, não usaria elementos de marcação de documento. É enlouquecedoramente detalhado. Também não é controlado o suficiente. No HTML, existe essencialmente uma maneira de escrever <p>Hello how are <b>you</b>?</p>. No GWT, você tem 3 nós filhos (texto B, texto) anexados a um Pnó. Você pode criar o P primeiro ou criar os nós filhos primeiro. Um dos nós filhos pode ser o resultado de retorno de uma função. Após alguns meses de desenvolvimento com muitos desenvolvedores, tentar decifrar a aparência do seu documento HTML rastreando seu código GWT é um processo indutor de dor de cabeça.

No final, a equipe decidiu que talvez usar o HTMLPanel para todo o HTML fosse o caminho certo a seguir. Agora, você perdeu muitas das vantagens da GWT de ter elementos prontamente disponíveis no código Java para vincular facilmente os dados.

Usar CSS no GWT é uma porcaria.

Por anexo à abstração HTML, isso significa que a maneira como você deve usar CSS também é diferente. Pode ter melhorado desde a última vez que usei o GWT (cerca de 9 meses atrás), mas na época, o suporte ao CSS era uma bagunça. Devido à maneira como o GWT faz você criar HTML, geralmente você tem níveis de nós que você não sabia que foram injetados (qualquer desenvolvedor CSS sabe como isso pode afetar drasticamente a renderização). Havia muitas maneiras de incorporar ou vincular CSS, resultando em uma confusão de espaços para nome. Além disso, você tinha o suporte a sprite, o que novamente soa legal, mas na verdade modificou seu CSS e tivemos problemas com a criação de propriedades que precisávamos sobrescrever explicitamente mais tarde ou, em alguns casos, frustraram nossas tentativas de combinar com nossa mão. codificado em CSS e tendo que apenas reprojetá-lo de maneira que o GWT não estragasse tudo.

União de problemas, interseção de benefícios

Qualquer idioma terá seu próprio conjunto de problemas e benefícios. Se você o usa, é uma fórmula ponderada com base naqueles. Quando você tem uma abstração, obtém uma união de todos os problemas e uma interseção dos benefícios. O JavaScript tem seus problemas e é comumente ridicularizado entre os engenheiros do lado do servidor, mas também possui alguns recursos úteis para o rápido desenvolvimento da Web. Pense em fechamentos, abreviações de sintaxe, objetos ad-hoc, todo o material feito pelo Jquery (como a consulta DOM pelo seletor CSS). Agora esqueça de usá-lo no GWT!

Separação de preocupações

Todos sabemos que, à medida que o tamanho de um projeto aumenta, é essencial ter uma boa separação de preocupações. Uma das mais importantes é a separação entre exibição e processamento. A GWT tornou isso muito difícil. Provavelmente não é impossível, mas a equipe que eu fazia nunca teve uma boa solução e, mesmo quando pensávamos que tínhamos, sempre tínhamos um vazando no outro.

Área de trabalho! = Web

Como o @Berin Loritsch postou nos comentários, o modelo ou mentalidade para o qual o GWT é desenvolvido é para aplicativos vivos, em que um programa tem um monitor ativo firmemente acoplado a um mecanismo de processamento. Parece bom, porque é isso que muitos acham que falta na web. Mas existem dois problemas: A) A web é construída em HTTP e isso é inerentemente diferente. Como mencionei acima, as tecnologias criadas em HTTP - HTML, CSS, até carregamento de recursos e cache (imagens etc.), foram criadas para essa plataforma. B) Os desenvolvedores Java que estão trabalhando na Web não mudam facilmente para essa mentalidade de aplicativo de desktop. A arquitetura neste mundo é uma disciplina totalmente diferente. Os desenvolvedores Flex provavelmente seriam mais adequados ao GWT do que os desenvolvedores da Web Java.

Em conclusão...

O GWT é capaz de produzir aplicativos AJAX rápidos e sujos com bastante facilidade usando apenas Java. Se rápido e sujo não soa como o que você deseja, não o use. A empresa em que eu trabalhava era uma empresa que se importava muito com o produto final, e seu senso de polimento, visual e interativo, para o usuário. Para nós, desenvolvedores de front-end, isso significava que precisávamos controlar HTML, CSS e JavaScript de maneiras que tornavam o uso do GWT uma tentativa de tocar piano com luvas de boxe.

Usamos o GWT para um grande aplicativo da Web de governo eletrônico (SOA no back-end), que tem um uso pesado. A interface do usuário antiga estava em DHTML, mas tivemos problemas com a compatibilidade do navegador, a otimização do desempenho e o processo de desenvolvimento, por isso procuramos alternativas.

Nossos requisitos foram:

• camada de interface do usuário do lado do cliente para minimizar a carga do servidor
• compatibilidade do navegador
• RIA baseado na web
• Otimizações fáceis de desempenho
• Nenhuma instalação de plug-ins de cliente necessária, deve funcionar com uma instalação simples do Windows

Escolhemos o GWT e nunca me arrependo. A nova equipe não possuía nenhuma experiência com DHMTL ou, portanto, o processo de desenvolvimento Java do GWT foi muito útil. O que você recebe da caixa é:

• compatibilidade do navegador
• Processo de desenvolvimento baseado em Java e reutilização de código
• minimização fácil de solicitações (pacote de imagens, ...)
• cache agressivo fácil (novos aplicativos são completamente armazenados em cache no lado do cliente)
• compressão fácil de todos os recursos (mesmo com js em IEs de buggy mais antigos)
• e muito mais, muito a mencionar aqui

Nosso aplicativo emite apenas uma solicitação para o servidor na inicialização. O lado negativo é que o GWT (e também o Android) tem um design ruim, mas de qualquer maneira, se você aplicar sua própria aparência, precisará adaptar o CSS. Como alternativa, você pode usar várias bibliotecas de componentes para o GWT, o que facilita a aplicação de estilos e temas adequados.

Para mim, não há sentido em que talvez o DOM HTML não seja tão bom quanto artesanal, isso nunca foi um problema. Quando desenvolvo em C ++, não olho para o código do assembler gerado. Quando desenvolvo no GWT, nunca houve uma razão para eu olhar o código JS e apenas uma vez uma razão para olhar para o DOM e refatorar.

Para mim, o GWT é a única opção no que diz respeito ao desenvolvimento da RIA e espero que o GWT tenha um futuro brilhante. Veja a declaração de missão em:

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

Mas não se deve mencionar que o Google não usa o GWT em muitos de seus projetos internos e que, no momento, existem alguns rumores sobre o futuro do GWT, consulte

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC