Um movimento freqüente que vemos nas listas de discussão e que também se manifestou no Just Java 2005 foi o interesse pelo futuro das letras V e C do MVC: Struts ou JSF?
Craig McClanahan, idealizador da Struts e um dos especificadores do JSF, catapultado pela SUN para trabalhar com James Gosling em sua ferramenta (caixa-preta) com base em JSF, promete competição com o WYSIWYG RAD do .NET...mas será esta a melhor opção para suceder o - já maduro – framework Struts em nossas arquiteturas MVC J2EE? O paradigma WYSIWYG RAD é mesmo o melhor para produção de interfaces Web?
Identificamos no Just Java, a partir das visitas que recebemos em nosso stand, o desconhecimento da maioria acerca do mais novo ingrediente nesta briga, o OpenLaszlo! (http://www.openlaszlo.org)
Quando os visitantes indagavam a respeito: "o jCompany irá para JSF ou se manterá na Struts?" Respondíamos com outra pergunta: "Você já conhece o Laszlo?". E 100% das respostas ainda eram: "Não"! Após apresentarmos o Laszlo, conseguíamos uma preferência "unânime" pelo produto, e não é difícil compreender o porquê.
Por este motivo, através deste artigo pretendo apresentar o Laszlo como contribuição para quem não pôde ir ao Just Java e ao stand da Powerlogic, e que está às voltas sobre qual rumo a tomar; ou mesmo para aqueles que já se decidiram, mas ainda estão em tempo de recuar.
Laszlo: Rich Internet Application
O Laszlo é um produto focado na camada Visão, tal qual o JSF. Ambos têm 90% de "área comum". O JSF tem intenções de "cobrir" a camada controle, mas ainda é muito fraco neste setor, tanto que estamos para ver nascer o Struts Shale, do próprio Craig, para complementá-lo - em suma, ou usamos Laszlo ou usamos JSF!
O Laszlo tem origem comercial e já competia com diferenciais com o Flex da Macromedia e outras iniciativas menos robustas com base no plugin Flash. Mas em dezembro do ano passado a empresa recebeu um aporte de capital de investidores japoneses e abriu seus produtos para o mundo Open-Source!
Como outros produtos Open-Source de origem comercial, o Laszlo é bem acabado e possui documentação extensiva, além de um portal e suporte bem organizados. Mas qual seria a estratégia dos japoneses? Bom, segue o rumor de que o Laszlo será utilizado como padrão de interface interativa da TV Digital no Japão (e veremos que tem qualidade potencial para isso), e daí podemos desconfiar de alguma coisa.
Laszlo x JSF
O Laszlo, com suas interfaces "cinemáticas" (coisa de cinema!), tem poder de ruptura na camada Visão (quem não estava usando MVC poderá ser obrigado a refazer suas aplicações em alguns anos) e tem o poder de "encantar" usuários finais, entregando real diferenciação se comparado a modelos de interface Web anteriores, com base em HTML ou variantes.
Se valendo da onipresença do plugin Flash, o Laszlo possui características de animação built-in como "tab panels com fadings, multi-skin, controles de alto nível, acompanhamento de foco animados, drag-and-drop, etc.", inclusive superiores às APIs gráficas de interfaces desktop! Tudo isso sem abrirmos mão de aplicações Web integradas a portais (impossibilidade do mundo desktop), J2EE MVC, sendo acessadas por clientes, parceiros e fornecedores - o Laszlo tem um bundle com o Tomcat e um exemplo "hello word" integrando com o Struts.
Já o JSF, em contrapartida, hoje atenderá meramente ao objetivo de seguirmos a especificação J2EE (refactoring), mas não irá agregar resultado visível para usuários finais de nossas aplicações. Estes continuarão vendo o velho "HTML" em Browser ou algo similar ao que já conhecíamos no Struts - aliás, em estágio muito mais avançado e maduro, incluindo integração com JSTL, Tiles (OO na camada View) e com muitos cases em produção.
Conclusão
Em enquetes que fizemos com nossos clientes, sobre iremos para JSF ou fazermos, em um primeiro momento, um suporte Viewer para Laszlo, a decisão foi unânime pelo Laszlo. Portanto, estamos para ver se o JSF irá sobreviver ao Lazslo ou conviver com ele...mas o Laszlo já mostrou a que veio!
"Lei de Darwin" (Open-Source) x "Lei do JSR" (Comitês J2EE)
Para aqueles que, mesmo após conhecerem o Laszlo, ainda se interessarem pela discussão JSF, segue este apêndice:
Todos já conhecemos vários exemplos sobre o sucesso de padrões "de-facto", surgidos da "seleção natural" promovida pelas comunidades Open-Source, sobrepujando os padrões "de comitês" J2EE. O exemplo mais gritante é o fracasso do JDO (para quem nem conhece, é o padrão J2EE para persistência de objetos) em prol do perante o Hibernate (este todos conhecem).
A especificação do JDO pretendia uma persistência que funcionasse para SGBD-R, LDAP, Arquivos Convencionais ou toda a sorte de "meios de persistência" que possam surgir. O Hibernate se ateve aos SGBD-Rs, e procurou fazer isso bem feito. O primeiro hoje é conhecido como o "pato" -nada, anda e voa, mas não faz nada direito! Já o segundo, é o padrão que está sendo agora incorporado em grande parte da especificação EJB 3.0.
Preocupados em seguir a especificação pré-definida (JSR), os implementadores perdem a capacidade de se adaptar quando se deparam com inviabilidades manifestadas na concretização da "concepção teórica" inicial, ao contrário do Open-Source, conduzido de forma "agile". E assim entendemos porque os princípios ágeis funcionam com mais frequencia:
- a evolução de um produto Open-Source de sucesso nasce de uma idéia, logo seguida de uma implementação prática, e de experimentações e adaptações a partir do uso. Como não há grandes valores envolvidos, produtos ruins são logo descartados (ao contrário do "agora temos que engolir" de opções comerciais dispendiosas), produzindo um ambiente propício para a "seleção e evolução natural" do mais apto, bem similar às leis que regem a natureza (Lei de Darwin).
- a evolução em comitês do J2EE nasce de um interesse combinado entre fabricantes de produtos e o mercado, gerando um documento (especificação em si), seguido de implementação básica de referência (sem muita experimentação) buscando atender a esta flexibilidade "antecipada" pelo comitê. Um processo parcialmente democrático, mas ainda assim "monumental", que dificulta a adaptação (vide como é lenta a adaptação dos implementadores de produtos EJB e JDO, mesmo após se depararem com as deficiências práticas no mercado)
Struts e JSF
O JSF está hoje tentando fazer hoje, na camada de Visão (principalmente), o que o JDO tentou fazer na camada de Persistência, sem sucesso: um modelo independente de formato de saída (html, xml ou o que for). Muitos argumentam que a melhor opção seria usar uma IDE/plugin apropriada para cada formato (especializada).
Um outro objetivo questionável (para a comunidade, não para a SUN) seria o interesse específico desta empresa em ganhar dinheiro com ferramenta fechada, concorrendo com o .NET com as mesmas "armas": um modelo de eventos RAD para Web. Mas esta seria mesmo a melhor opção para desenvolvimento Web?
Quando fazemos coisas fáceis, pode ser, mas quando necessário nos recorrermos ao código (para as coisas difíceis - e isso vai acontecer), então fica quase impossível se caminhar na pesada camada de eventos.
Nota: OpenLaszlo é uma plataforma de código aberto descontinuada para o desenvolvimento e entrega de aplicativos para Internet. É lançado sob a Licença Pública Comum (CPL) da Open Source Initiative (OSI).
A plataforma OpenLaszlo consiste na linguagem de programação LZX e no servidor OpenLaszlo.
LZX é uma língua de marcação extensível (XML) e linguagem de descrição de JavaScript semelhante em espírito para XUL, MXML e Extensible Application Markup Language (XAML). O LZX permite um processo de desenvolvimento declarativo e baseado em texto que suporte práticas de prototipagem rápida e desenvolvimento de software. Ele é projetado para ser familiar aos desenvolvedores de aplicativos da Web tradicionais que estão familiarizados com HTML e JavaScript.
OpenLaszlo Server é um servlet Java que compila aplicativos LZX em binários executáveis para ambientes de tempo de execução específicos.
