Atualmente ando preparando alguns novos projetos web. A primeira dúvida que surge hoje em dia é qual tipo de visualização usar, e por conseguinte qual tecnologia Java usar. Tendo em vista o futuro promissor do HTML 5 – que embora eu tenha duvida que irá vingar no mundo corporativo, não tenho duvidas que vingará na internet publica – e o desalento dos criadores de browsers em boicotar o uso de plugins (a criação matou o criador) nos quais se inclui o Java.

Portanto pese embora o esforço da Sun e depois da Oracle em empurrar o  JavaFX como alternativa visual para o java substituindo em cada plataforma a forma nativa de UI e UX (user experience) o tempo e a concorrencia parecem ter ganho a batalha inicial. O JavaFX perdeu no campo dos celulares e tabblets  para o Android  e foi proibido no iPhone e iPad. Na Web perdeu para o HTML 5 e no desktop … bom, quem usar desktop em java , afinal ?

O JavaFX foi criado para competir com o Flash e o Silverlight. Mas a Revolta dos Plugins iniciada pela Apple e seguida pela Mozilla e agora pela Microsoft em proibir o uso de plugins em browsers e suportar HTML 5 em vez, matou o Flash e o Silverlight antes sequer do FX vingar como competidor nesse campo. É como se o campo de batalha tivesse sido removido e o Fx chega todo armado até aos dentes para encontrar um vácuo onde nada existe mais. A alternativa é ainda vender o FX para celulares e o JME 3 com equiparação JSE 7 (uau!) e com isso criar aplicativos iguais ou melhores que os dos android ou iphone. No andoid a gerra esta perdida, quanto a mim, mas no mundo do iphone ainda ha esperança de vermos um compilador nativo que  compila um jar junto com a JVM e joga tudo em formato binário indistinguível daquele que o  SDK da Apple gera. No desktop poderíamos ver o uso do JWS para difundir novos aplicativos RIA. Com o projeto jigsaw do java 8 isto é ainda é uma possibilidade real para aplicativos, sobretudo se o JWS poder ser instalado via os  Markets da vida seria uma forma, quase viral, de trazer o java de volta tanto no mercado corporativo como no mercado publico.  O JWS é de fato o avô do conceito de Market, e hoje que todo mundo entende o conceito seria muitos mais simples vender o conceito de aplicações instaláveis remotamente. Os novos applets seriam servidos por Markets e não por simples Browsers.

A promessa de um cross-compiler de javaFX para HTML 5 seria a opção matadora e a arquitetura do Fx 2 parece levar isto em consideração. Mas quando poderemos ver isso em produção e será mesmo que vai acontecer ? Estas duvidas tolham o processo de escolha.

Pessoalmente adoro trabalhar com Swing e acho  cem vezes mais produtivo do que qualquer coisa baseada em request-response. Portanto o Fx vem mesmo em boa hora. Mas é o futuro ?

Por outro lado, temos coisas com o Play Framework  que já prometer um novo mundo de programa em Java (ou scala) e corra onde quiser. Baseado em GWT e no compilador java-javascript a magia está pronta para acontecer. Mas e o vendor lock-in ?

O mesmo acontece com frameworks como o Wicket e o Vaadin que embora não prometam a integração HTML5 conseguem-se aproveitar dessa tecnologia e o programador apenas programa em Java (bom o Wicket ainda exige criar as páginas em HTML o que eu acho desproposital). As UI são swing-like e a UX é a de um aplicativo desktop. Não são tecnologia para usar em uma loja virtual, mas para sistema corporativos parecem bem decentes. Mais um vez, o problema do Vendor Lock -in aparece como um contra. Nem sempre as decisões arquiteturais dos criadores vão de encontro às necessidades e podemos assistir a um Struts novamente (sendo abandonado pelo seu primo Struts 2).

Se o Struts no ensinou algo é que não podemos abraçar a tecnologia emergente sem pensar nas consequências.  ninguém previu o abandono do Struts, cegos com a novidade as pessoas escolheram não ver os problemas arquiteturais que o Struts tinha. Relegado ao esquecimento e proibido de usar pelos seus próprios criadores na Apache que decidiram correr para o Struts 2. O mesmo aconteceu com o JSF 1.0 que foi modificado em tantas coisas para se transformar no JSF 2 ( quase tanto como o Fx 1 foi modificado para o Fx2). Nos dá a impressão que ainda não chegamos em um nível de maturidade  em frameworks web, mas está claro que frameworks request-response não dão conta do recado em ambiente corporativo onde ha necessidade forte de lidar com inputs e os writes são quase tantos quantos os reads.

Então, espelho meu, qual é a melhor view que eu ?

O Struts está acabado e qualquer um é melhor que ele. Os frameworks request-response são quase iguais em todos os aspetos, com o Spring MVC correndo na frente apenas porque integra o spring nativamente ( para os outros os spring é uma biblioteca de apoio e nao o core).  Estes frameworks nos dão o controle, mas não a view. Ai vem o JSP ou frameworks de formatação com o Freemarker e o Velocity. Bah! é tudo igual. Não ha componentes poderosos. Temos que os criar. Provavelmente em JQuery e usando alguma integração jquery-java muito louca.

Tiles, Sitemesh  e semelhantes não são frameworks de componentes e sim de template web. Utils para reorganizar o layout, mas inúteis para criar componentes ( não que não seja possível, mas ninguém faz isso)

Bom, parece que a cada uma que coloquemos diante do espelho, sempre existirá alguma melhor. O que fazer ?

A resposta é realmente simples, mas normalmente descartada facilmente pelos desenvolvedores.  A resposta é isolar a view. Afinal é um andar diferente na arquitetura e deve ser tratado como tal. Acontece que não é assim que as aplicações são desenvolvidas. Quantas aplicações você conhece ou fez em que pode mudar de struts para JSF e não perder as logicas de negocio ? Afinal, os programadores insistem em programar lógicas nas actions do struts ou nos managed beans do JSF, certo ? Como migrar isso. Impossível.

Este problema advém do mau entendimento e uso do padrão Bridge (também chamado Mediator). Este padrão é muito útil e a prova dele está na JDBC que é implementada com esse padrão. A ideia é que você tem duas partes do sistema A e B em que ambas podem evoluir independentemente uma da outra e sem causar alterações ou recompilações na outra. O design disto não é trivial e por isso mesmo seria ideal que um framework existisse que provesse esta arquitetura, e é deste santo graal que estamos à espera.

À priori todos concordam que não faz sentido mudar ou cria mais código em business para suportar uma tela que migrou para ajax. Se ela mudar para HTML 5 temos que mudar de novo ? e para JSF ? ou para FX ? Afinal o business depende da view ? Em tese não. Não prática sim, na avassaladora maioria dos casos. E é aqui está o custo de migração. E porque o custo de migração é alto a escolha prévia da tecnologia implica num alto risco.

A solução então é seguir a máxima da arquitetura moderna : deixe suas opções abertas. E a forma de testar se isso é verdade é implementar pelo menos 3 clientes diferentes para o seu andar de apresentação e usar o mesmo business para cada um.  Isto é o futuro. Porque assim, não importa qual a view que usar nem como os browsers vão evoluir, a sua aplicação ainda fará o mesmo.

Por outro lado, mudar de view é o que diferencia as versão de um software. Portanto, comercialmente é interessante evoluir a view a gosto da moda, mas financeiramente não é interessante reescrever as regras de negócio cada vez que fazemos isso. A única forma é portanto utilizar o padrão Bridge, isolar a view do resto e escolher a view do momento.

Fácil ? Não é fácil. Mas se fosse, qual seria o desafio ?

Curiosamente, todo sabem que esta é a resposta certa, mas rapidamente ela é descreditada com frases feitas como “Não temos tempo agora” , “Não está no escopo” , “Não temos orçamento” … tá. Mas temos orçamento para bancar os custos de manutenção em tecnologia obsoletas, e refazer a mesma coisa N vezes …

Esta dúvida sobre qual view é melhor não advém apenas da necessidade de escolhas para novos sistemas, mas também como dúvida sobre qual tipo de framework de view prover no MiddleHeaven. Por enquanto temos o feijão-com-arroz do JSP ou Freemarker, mas como disse isto não provê componentes nem manutenção fácil no futuro. A ideia de um padrão Bridge parece ser a única que faz sentido aqui , mas é muito fácil. O padrão de programação visual é Event Driven como o Swing, não importa como mascaremos isto, isto é o que queremos realmente usar.

Seria interessante ter o vosso feedback do que estão usando, prós e contras e se concordam que isolar a view é a forma segura de prosseguir.