eu estava recentemente falando com um amigo sobre o desenvolvimento de IU. Ele também tem sido um programador desde que a programação foi considerada uma arte Arcana (quando aqueles de nós que fizeram isso foram considerados como Gandalf, o cinza de frente para o Balrog). Ou talvez nos víssemos assim. Independentemente disso, nós dois temos sido programadores Java por uma grande parte desse tempo.
ambos lamentámos o facto de ter sido uma mudança de contexto para passar de codificar a maioria dos nossos projectos em Java, necessitando então de mudar para JavaScript para o front end.Com base em conversas que vi online, vários leitores estão a aquecer os teclados para me repreender por me queixar de ter de codificar em JavaScript. Mantenha suas chaves legais, nós e nossos colegas de trabalho temos experiência e prazer em escrever, JavaScript e qualquer um de seus frameworks para nossos clientes. Mas usar JavaScript nem sempre é a melhor abordagem.
neste post, introduzimos dois frameworks que lhe permitem codificar a sua interface de utilizador em Java: GWT e Vaadin.Quando utilizar Java para a IU?
a conversa voltou para mim enquanto eu estava falando com um cliente — uma pequena loja de apenas um par de programadores e um arquiteto de software que também programou. Eles tinham decidido que não queriam manter seus projetos em duas línguas separadas. Sua empresa tinha padronizado em Java, e eles queriam usar as mesmas ferramentas e mentalidade para criar interfaces de usuário poderosas e modernas para suas aplicações web.
tenho notado em equipas maiores que a equipa parece separar-se, alguns preferem concentrar-se no front-end, e outros a trabalhar principalmente no back-end ou no código do servidor. Quando o trabalho é aprovado para o desenvolvimento, muitas vezes eu vejo os mesmos programadores tomando ou recebendo a maioria do trabalho JavaScript front-end, e outros assumindo o back-end.Não estou dizendo que isto é uma coisa ruim; na verdade, parece ser exatamente o oposto. Todos parecem ser mais produtivos em sua zona de conforto, mas todos também estão cientes do que todos os outros estão fazendo e podem entrar nessa zona se ou quando necessário. Para lojas mais pequenas, esta não é uma opção. Muitas vezes, o mesmo programador irá escrever o código de um projeto inteiro da interface do Usuário para o modelo.
felizmente, existem escolhas se você deseja manter a sua interface de usuário na mesma língua que a sua back-end se essa linguagem é Java. Vamos falar sobre alguns deles agora.
GWT
Google Web Toolkit, ou GWT, é uma excelente opção.Tive muito sucesso com a GWT num projecto que iniciei há cerca de 8 anos e que ainda mantenho. GWT me permitiu construir a lógica de visualização para uma aplicação de uma única página completamente em código Java padrão. Vem com um plugin Eclipse. Não o usei porque usei Netbeans para o meu ambiente de desenvolvimento, mas como o Eclipse é o padrão para a maioria das equipas, isto pode ser muito útil.
I was able to break down the logic for widgets( such as a custom text box), into classes or helper methods, just as I would business logic on a server-side project. Através da herança, eu era capaz de criar vários widgets que tinham requisitos semelhantes facilmente. Sobre o único conceito real de mudança que eu tive que lidar com era que a IU é muito mais motivada por eventos do que a maioria dos serviços web ou outro código do lado do servidor.
há duas desvantagens primárias que eu vejo para GWT. Um é o tempo de compilação. GWT adiciona uma etapa de compilação ao processo que leva algum tempo. As classes GWT que foram construídas em Java devem ser compiladas em bibliotecas JavaScript. Vi várias queixas sobre o tempo que isto leva.
a segunda é que já passou bastante tempo desde a GWT ter visto uma atualização significativa. A partir desta escrita, 2.8.2 foi lançado há mais de um ano em outubro de 2017. Três anos antes, 2.7.0 foi lançado, tornando-se quatro anos a partir do momento desta escrita. Eu vejo postagens e comentários sobre 3.0 saindo, incluindo cerca de dois anos atrás, perguntando se o cartaz deve esperar para 3.0 para sair antes de implementar uma grande mudança (espero que o cartaz não está ainda à espera), mas eu não posso encontrar qualquer prazos para quando o lançamento poderia estar de fora.Embora eu seja um grande fã do framework e considere-o maduro o suficiente como é, eu sei que essa imprecisão na possibilidade de lançamentos futuros deixa alguns gerentes de projeto um pouco nervosos. Ninguém quer ser amarrado a uma estrutura que não dá em nada.
GWT é uma biblioteca que eu vou continuar a usar e sugerir a outras equipes para usar se ele atender às suas necessidades.
Vaadin
Vaadin é outra grande opção.
originalmente pensei que o GWT era a minha única escolha para escrever interfaces de usuário em código Java padrão. Mas quando falei com aquela pequena loja que mencionei acima, eles me disseram que tinham decidido usar Vaadin para seus projetos. Por isso, claro, tive de ir dar uma vista de olhos. E estou impressionado.Vou ser honesto, a partir desta escrita, ainda não usei Vaadin para criar um projeto. Mas estou a aumentar alguns projectos pessoais para os quais preciso de front-end e pretendo usar isto. Se Vaadin cumprir as suas promessas, será um quadro perfeito para estes projectos.Vaadin promete apoiar línguas que funcionam no JVM, como Kotlin e Scala. Espero que isso inclua Groovy. Se você ler muitos dos meus posts anteriores, você vai saber que eu sou um fã dessa linguagem, porque você pode rapidamente criar um código que pode ser facilmente mantido. Estes são requisitos importantes para mim, especialmente a manutenção. Nada destrói mais um projeto ao longo da estrada do que não ser capaz de manter facilmente o código que já foi escrito.
Pensamentos finais
tem muitas opções ao arquitectar a sua aplicação web quando se trata de tecnologia de interface do utilizador. Quer esteja a arquitectar um projecto ou um ambiente de produção, tem tantos requisitos a ter em mente.
dois requisitos que você deve ter em mente são a facilidade de desenvolvimento e manutenção.
- um ambiente de desenvolvimento em que é difícil trabalhar irá resultar em muitas derrapagens de custos e tornar os novos programadores muito difíceis.
- um projeto que é difícil de manter causará frustrações e desperdiçará mais dinheiro no futuro.
com base nas necessidades e requisitos da sua equipa, uma solução Java completa, da interface do utilizador ao modelo, não só é possível como é uma grande escolha tanto para o desenvolvimento rápido como para a facilidade de manutenção.Acredita no bom código.